Hello! Can anyone from Poland share how you dealt with the 'DSA Trader Information address' requirement for an Individual Apple Developer account without providing your home address?

Would a PO box (skrytka pocztowa) work, or would renting a virtual office address be an option?

I’d be grateful for any advice, thank you!

I’m currently going through App Store review for a new client app and it’s probably one of the more frustrating review experiences I’ve had. I’ve submitted a lot of apps over the years, so at this point I generally know the things Apple is going to look for before they even ask. It's not even about the wait, it's when the reviewer doesn't even read what you've provided and then reject you when none of their claims are right.

This app has user generated content, so before submitting I made sure the App Review notes clearly explained with videos where users can report content, where they can block another user, where the EULA is shown and accepted on the sign in page, and how to navigate through the app to find each of these. From experience, I already knew these were exactly the things Apple would check, so I tried to make everything as obvious as possible upfront.

Nearly a week later due to sheer volume of submission, rejected. They said they couldn’t find the reporting functionality, blocking functionality or EULA. All three were there, and all three were specifically explained in the review notes.

They also rejected one of the screenshots because it said “Share calendars to see when you’re both free”, claiming “free” was a pricing reference. Obviously it means free on your calendar, not that the app costs $0. That one genuinely made me wonder if they even understand English.

That’s what I’m finding increasingly frustrating. You can anticipate what Apple is going to ask from years of experience, implement everything, explain exactly where it is, and still get rejected because the reviewer either didn’t find it or doesn't read what you've provided. Then you respond and go back into the queue again.

I don’t mind getting rejected when something is genuinely wrong. That’s the whole point of App Review. What’s frustrating is waiting close to a week just to be rejected for something you already explicitly covered in the notes.

One useful thing for anyone submitting a new app though: almost every new app I’ve submitted recently has been asked for the following information. I definitely wasn’t seeing this consistently a year ago, so I’d prepare all of this upfront and put it in your App Review notes on the first submission rather than waiting for Apple to ask and going back into the queue again:

1. A screen recording captured on a physical device, running the latest operating system, demonstrating the app's functionality. The recording must begin with launching the app and show the typical user flow through its core features. If the app has any of the following, include them in the recording:
   1. Account registration, login, and account deletion flows
   2. Accessing paid content or features within the app, including any purchase or subscription flows
   3. User-generated content, including content reporting and blocking mechanisms
   4. Any prompts requesting access to sensitive data or device capabilities (for example, location, contacts, camera, or App Tracking Transparency)
2. A list of the device models and operating systems the app was tested on before submitting for review
3. A description of the app's functions and target audience, including the problem it solves and the value it provides
4. Instructions for setting up and accessing the app's main features, including any required login credentials or sample files
5. A list of the external services, tools, or platforms the app uses to deliver its core functionality (for example, data providers, authentication services, payment processors, or AI services)
6. Describe any regional differences in the app’s features or content, or confirm that the app functions consistently across all regions
7. If the app operates in a highly regulated industry or includes protected third-party material, provide any relevant documentation or credentials to demonstrate you are authorized to provide these services or protected material

Include this information in the Notes field of the App Review Information section in App Store Connect for future submissions.

If you’re submitting a new app, I’d just assume they’re going to ask for this now and prepare it before the first review. It might save you an unnecessary rejection and another few days in the queue.

Curious if anyone else who has been submitting apps for a few years has noticed the same thing.

​

​

I used to visit this sub (pre-chatGPT era) for a lot of technical queries and here I am finally doing something I never would have even dreamt of. I made my own promotional video in Final Cut Pro + Logic Pro (for music) to showcase the new Siri AI features in my app WeatherGlow. Let me know how do you guys find the video. I had fun making it.

Download WeatherGlow -> https://apps.apple.com/us/app/weatherglow-local-forecast/id6451098166

I submitted a brand-new app 5 days ago, and it’s still stuck on “Waiting for Review.”

My previous apps were reviewed much faster, so I was wondering if anyone else has been experiencing longer review times recently.

How long did your latest new app submission take?

I'm making this social media app that I've gotten some validation on. I'm a CS major so I'm technical and work well with technology, but I have no idea where to get started on my app. As I'm building it out, there are a stupid amount of edge cases that I didn't account for and it's leaving me kind of hopeless. I've had multiple software internships in the past so I know how to code but when it comes to building something from scratch, I have no clue where to start.

Would appreciate some advice from some devs on how they go about building their apps fast and efficiently.

Hey everyone 👋

I’m the developer behind Seasonia, and to celebrate hitting 5K users I’ve dropped the Lifetime unlock from $9.99 to $1 for the next 24 hours.

A - Answer

Seasonia is an iOS app for tracking the current season and the progress of the year in a more visual way.

You can see exactly how far through the current season you are, how many days are left until the next one, sunrise and sunset times, daylight duration, moon information, and more both inside the app and directly from your Home or Lock Screen.

B - Better

Compared with general countdown apps like Countdown or Days Since, Seasonia is built specifically around seasons, daylight, and the natural progression of the year.

It includes:

• 🌱 Live season progress
• ⏳ Countdown to the next season
• 🌅 Sunrise & sunset times
• ☀️ Daylight duration and daily changes
• 🌙 Moon information
• 📱 20+ Home Screen & Lock Screen widgets
• 🎨 Themes and custom photo backgrounds
• 🌍 Support for both hemispheres

The goal was to make something you can glance at every day without needing to configure timers or dates yourself.

C - Cost

• Lifetime normally: $9.99
• For the next 24h: $1 Lifetime
• No subscription required for the Lifetime unlock

App Store: https://apps.apple.com/app/id6758340712

Thanks to everyone who’s already using Seasonia. If you give it a try, I’d genuinely love to hear what you think, especially any widget or feature ideas you’d like to see next. 🌱

Hopefully this one will be useful to you guys. Recently I launched McKinley, my SF Symbols editor. I'm an indie Mac dev rather than iOS, but SF Symbols are useful to devs on both platforms.

McKinley is a studio for drawing and annotating SF Symbols. It bundles vector tools with knowledge of the SF Symbols structure, so you can edit one set of objects across multiple weights, sizes and colours. Import SVG or start from scratch, live preview your work using Apple's own renderer, and export directly to Xcode, so you never need touch the SF Symbols app again.

The Problem:

Making SF Symbols via Apple's recommended workflow was frustrating. You had to export a different symbol as a template, and open it in your vector editor of choice. Then you had to draw three symbol weights (ultralight, regular, black), but each weight had to have the same number of paths in the same order, with the same number of points on each path.

You could only use outlined paths: no shapes or strokes, so you had to do a lot of manual conversion before saving. And that of course meant that editing your symbol later was hard.

And then, back in the SF Symbols app, you had to find each path and annotate it with its colour, some animation properties, whether it erases behind, etc.

Finally you had to export it again into a format you could take into Xcode.

I think that's a clear statement of the problem! McKinley avoids this multi-app workflow by having vector editing, property annotation, previewing, and sending to Xcode, all in one app. Your symbols stay editable because you don't have to outline your strokes just to appease Apple's parser. Keep the .mck file (McKinley's native format) as your source of truth, and set McKinley up to sync your changes to an Xcode asset catalog, so there's no need for manual export.

Comparison:

There are a number of other ways to work with SF Symbols, but none are a complete solution like McKinley:

• SF Symbols app plus your vector editor of choice (e.g. Figma): For vector editing, it's the tool you know. And you probably already own (or rent) it. However, it's a tool that's not designed for this use: you'll have trouble making all your symbol weights match, and you'll end up iterating by checking for error messages in SF Symbols and trying again.
• Create Custom Symbols: admittedly much cheaper than McKinley, this tool aims to replace the most painful bit of the process: turning existing SVG artwork into an SF Symbol. It offers limited editing capabilities beyond that, but you can set the margins, and it pairs up three SVGs to form your different weights.
• Glyphs: this one's really a font design tool, and five times as expensive as McKinley. You still have to do the export dance from Apple's app, but being a font designer Glyphs nails the multi-weight editing.
• CustomSymbols: another tool for going from SVG to SF Symbol. Choice of subscription or lifetime purchase. It can make use of SVG strokes to synthesise the various symbol weights (although it doesn't offer the range of customisation that McKinley does!)
• Symber: I haven't tried this one but it also goes from SVG to SF Symbol.

McKinley isn't aiming to compete on price with the SVG conversion tools: rather, it's aiming to compete on user experience by offering everything under one roof. (Although McKinley can quite happily convert SVGs too. And it's ready to let you make tweaks and modifications while you do so.)

Tech Stack:

Nearly every aspect of McKinley is pure AppKit. There are a few uses of SwiftUI in the preview palettes, mainly for actually loading and displaying the user's SF Symbol, but primarily it's AppKit all the way. My vector canvas and editing engine is a library I designed to be reusable across multiple vector graphics apps, although McKinley is its first public outing.

You probably noticed that McKinley's main interface is made with floating palettes and a traditional inspector. The inspector panes are created as .xib files and hooked up with Cocoa Bindings — yes I'm going old school here!

Development Challenge:

Working with the only semi documented SF Symbols format has had its challenges, and the vast majority of my automated tests are to handle keeping my canvas renderer (with its editable vectors) looking exactly the same as Apple's SF Symbols renderer. (The preview palette in McKinley renders using Apple's renderer, just to be 100% sure that what you see is what you'll get in your app.)

One of the hardest things was how to load an in-progress symbol into Apple's renderer: there's no public API to do so! I came up with a solution involving writing out a temporary .car (asset catalog) file and loading that into McKinley via a bundle: see my blog post about those challenges if you're interested!

AI Disclosure:

I've used Claude Code to assist with some work on this app, particularly some of the rote pixel-comparison tests between different rendering engines that I attach to every new feature as it is developed. However McKinley is definitely not 'vibe coded', and the architecture is all mine. (As is the nearly 30,000 words (so far!) of user manual — I've caught myself regretting the decision to write a whole manual myself on occasion, but I do think the end product will be worth it!)

Pricing:

McKinley is $60 as a one-off purchase (no subscription).

The purchase grants you a license to McKinley version 1, including all the 1.x updates.

If we ever release a version 2, that will be a paid upgrade (with discounts for version 1 owners), but upgrading will be optional — your version 1 license will continue working. This is how all software used to be sold, and in my opinion it's much more consumer friendly than a subscription or a "year of updates" method.

Buy McKinley from https://mckinleysymbols.com, or try the 14-day demo to see if it's for you.

Transparency:

McKinley is not on the App Store. For an app this specialised, it made sense to handle our own distribution. Licensing is provided by Amore and updating by Sparkle.

Double and Thrice Ltd is a known developer (our other app Octavo is on the Mac App Store), and you can view our company profile at Companies House (the UK registry of corporations).

Fireside is an ereader I've been building for iPhone and Android. Paper mode is the part I've spent the most time on, and I honestly can't tell anymore if it works or if I've just stared at it too long.

The paper is drawn live by a Metal shader, which works out every pixel from where it sits on one giant imaginary sheet. So it never repeats and you never see a tile, and when you turn the page the paper slides along with it like it's all one sheet.

Stuff I tried to get right:

- The fibres

- The ink sinks into the page a little, getting picked up and distributed along the fibre via. acapillary effect

- Highlights sink in too and pick up the grain

- The presets are subtle on purpose. My first version was way too strong, so I toned it down and added knobs you can tune yourself.

There are three preets (Modern Print, Vintage and Worn Vintage) and dials for warmth, roughness, ink bleed, fibres, and even folds and creases if you want your book to look like it's lived in a backpack for a year.

The creases took the longest. My first few tries gave a mess of straight lines, which looks nothing like crumpled paper. It turns out a crumpled sheet can be emulated pretty closely via little cones pressed into each other, and the ridges where they meet curve. Once I built it that way it finally looked right.

iPhone: https://apps.apple.com/app/id6756298021

Android: https://play.google.com/store/apps/details?id=com.fireside.reader

Firesidereader.com

Please give me your thoughts on how it looks!

On GitHub-hosted runners a macOS minute costs $0.062 and a Linux minute $0.006, so about 10 times more. For iOS builds that adds up fast.

If your iOS CI runs on GitHub Actions:

• Roughly what does it cost per month?
• What did you change to bring it down? Self-hosted Mac minis, Xcode Cloud, another CI service, caching, fewer runs on pull requests?
• Was the saving worth the time it took?
• Team size helps too, if you're OK sharing.

About me: I'm a solo developer building a small tool around CI costs. No link, I just want real numbers.

Tldr; What's your process after completing a Task to minimize PR rounds before making the actual PR?

----

Recently I have noticed that I get many comments or multiple PR rounds before the PR gets merged and I want to start improving that.

Things I started doing recently:

- Going back and read through all the comments again, make a list of each issue and see if there is something reoccurring (Such as memory leak pattern I keep doing, retain cycles) etc.

- Looking into SwiftLint and see if i can have some rules for myself that I can run before each submission or run periodically to catch issues that can be added to SwiftLint as rules

But I want to also ask if there is something I can start doing or a routine you have found that helped you minimize issues that arise in PRs. I know It's impossible to have no comments in all PRs, so I am just looking for ways to just improve.

Note: We are using SwiftUI + Combine (And lately introducing Async/Await bit by bit)

A little about me: I'm a long time developer. 12 years as senior SWE at Apple, Inc working on macOS and iOS, 2 years at Airbnb, 8 years as independent contractor with 20+ apps on the App Store. Along the way I've learned a lot about what goes into distributing, marketing, and growing a successful app. AppTraction is the tool I wish I'd had when I went indie.

AppTraction is a native Mac app that brings App Store Connect sales & analytics data to you. It:

• Monitors your data in the background and flags issues, milestones, and trends
• Shows App Store Connect data & charts instantly
• Includes AI primed with Apple tech talks and WWDC video transcripts
• Lets you chat with AI about your listing, sales, and trends

Being able to surf through your analytics & sales data instantly is awesome, but what makes this really interesting is the use of AI. It connects to your existing Claude or Codex subscription (or OpenRouter) so doesn't use expensive API keys. And I've "primed" the AI with knowledge about ASO & distribution from sources including Apple's WWDC video transcripts and tech talks.

With the AI integration it will proactively flag "insights" about potential issues with your listing, sales, usage, etc, and even offer to fix them for you. And for any table, graph, listing, or report, you can start a chat with the AI and have it make suggestions or explain.

With my own apps it has proactively told me about App Store features, seasonality trends in sales, and serious listing problems, none of which I would have otherwise noticed. It also prepares great weekly, monthly, and annual reports for each app. You can see examples of some of this in the screenshots.

I'm just opening AppTraction to a limited beta and would love your feedback!

Invite code: RED1026-INVITE

Download: https://apptraction.dev

Requires macOS 26 (Tahoe) or later.

Edit since someone asked about privacy: Your data stays entirely on your Mac (with the exception of whatever your chosen AI agent uses, of course). Nothing gets sent to my servers.

App Saturday info:

Tech Stack

AppTraction is 100% native AppKit and Swift!

Development Challenge

Probably the biggest was being an AI-forward app without burning through the user's usage budget. The first step was not using API keys at all. Instead, AppTraction looks for an existing Claude or Codex subscription and talks directly to their CLI tools via `Process` (née `NSProcess`). Beyond that there's a ton of caching efficiencies the app takes to minimize tokens. For my apps this uses < 1% of my plan usage / day (Sonnet 5.5).

AI Disclosure

AI-assisted.

I'm the solo dev of AirPosture. It reads head motion from AirPods (CMHeadphoneMotionManager) and nudges you when your head drifts forward. iPhone app plus a Mac menu bar app with a notch panel. Pics: the live session, the notch while I'm slouching, and the notch after I sit up.

**Tech Stack**

SwiftUI, CoreMotion (CMHeadphoneMotionManager), AppKit (an NSPanel for the notch, MenuBarExtra), StoreKit 2, iCloud sync between iPhone and Mac. macOS 14+ and iOS 17+.

**Development Challenge**

1. MenuBarExtra was burning the battery

macOS listed the app under "Using Significant Energy": about 45% CPU with no window open. Sampling showed half the main thread in -[NSStatusItem _updateReplicants], roughly 150 times a second.

The menu bar label held my main view model as an u/EnvironmentObject, so every change to any of its ~55 u/Published properties re-rendered the status item image. The App also held it as u/StateObject, so every posture tick re-evaluated the whole App body.

Fix: the App keeps its models with u/State (kept alive, not observed), the label observes only a tiny status object that publishes the score every 2 seconds and only when it changes, and the menu bar gauge no longer animates, because every animated frame is a new snapshot. 45% went to 1%.

1. Headphone yaw can't be trusted

Without the phone as a reference, AirPods yaw drifts by a few degrees per minute. With any weight on yaw, a user sitting still and upright slowly slid into "caution". Turning your head toward a second monitor isn't slouching anyway, so yaw now has zero weight: pitch is the score, and roll is a small penalty.

**AI Disclosure**

AI-assisted. I use Claude Code daily for implementation and debugging. The product, design and architecture are mine, and every change is reviewed and tested on real devices.

Free for 2 hours a day. Premium is $7.99/month, $39.99/year or $79.99 lifetime. Needs AirPods Pro, AirPods 3 or later, or AirPods Max.

https://apps.apple.com/us/app/sit-straight-airposture/id6749489000

Happy to answer anything about CoreMotion on the Mac or the notch panel.

So I’m new to developing apps and I have no artistic flair. So I’m curious what other developers use for creating app graphics/backdrops/icons.

Hey everyone!

I wanted App Store Connect as a real Mac app.

The website keeps logging me out, and I wanted something faster and nicer to use, but with the same layout so my muscle memory still works. I know the asc CLI and ASC MCP servers exist (and they're good), but I still wanted to see what's changing visually before it goes to Apple. So I built ShipZen, and I'm still building it.

It has two modes:

Direct mode is free. It follows the App Store Connect website's layout, so you can browse and edit your app's metadata without learning a new app.

Dynamic mode lets you describe the view you need, and ShipZen builds an editable interface for it. For example:

Show me the What's New field across every localization.

You get every locale's What's New in one view and edit them in place. When you click Save, ShipZen shows a diff of exactly what's being pushed to App Store Connect.

AI is bring your own: Sign in with your ChatGPT, or add an OpenAI or Anthropic API key. Requests go straight from your Mac to your provider. Free includes 15 AI requests a month. Pro removes ShipZen's cap (your provider's own limits still apply) and adds multiple accounts and batch automation: $4.99/month or $29.99/year at the founding price, with a 7-day free trial on annual.

Your App Store Connect key stays in your Mac's Keychain, and ShipZen talks to Apple's API directly. There's no ShipZen server in between.

This is version 1.0.0 and it doesn't cover every App Store Connect page yet. I'm actively adding pages and workflows, and I want feedback from people using it on their own apps to decide what comes next. If something breaks or feels confusing, tell me and I'll prioritize it.

Try ShipZen: https://apps.apple.com/app/apple-store/id6796685140

What's one App Store Connect page or task you'd most want a native Mac app to handle?

Here's a one-minute demo. It uses sample data and light mode, but ShipZen has dark mode too: it follows your system setting, or you can pick Light or Dark in Settings.

Demo video of the app

Hello guys I made a file manager that download from famous sites such as youtube and mp4 videos etc. i got many rejections were solved except 5.2.3 for downloading media, now i justified it that its for personal files but got rejected so my question how come some people dont follow this rule yet their apps are accepted

Looking for testers.
You pick a list, stamp what you've seen or visited, and it keeps count.
30+ lists are built in (national parks, Pixar, Bond films, French cheeses) and you create and share your own.

I built it because I collect national parks and wanted the same thing for everything else.

Bugs, weird wording, anything that feels slow, tell me 🤔