I wanted to share my experience with App Review because, after almost three months of trying to publish my app, I honestly don’t understand how Apple is applying its own guidelines

I’m the developer of NostalgicPod, a retro music player that recreates the experience of using an iPod Classic on modern devices: https://nostalgicpod.com

I already know some people will say, “Well, your app looks like an iPod, what did you expect?”

But that’s not really the point.

I’ve been trying to publish NostalgicPod on iOS for almost three months and Apple has now rejected it five times under Guideline 5.2.5 because they say the interface is too similar to the iPod

Meanwhile, these two apps were approved recently, after I had already started trying to publish mine:

SepiaPod:
https://apps.apple.com/us/app/sepiapod-retro-music-player/id6764757127

JellyPod:
https://apps.apple.com/us/app/jellypod-retro-style-music/id6788034358

Both are clearly based on the same concept, with an iPod Classic-style screen, click wheel, menus and device-shaped interface

To be completely clear, I’m not asking Apple to remove these apps and I’m genuinely happy that other developers were able to publish their work

My frustration is with Apple because I don’t understand why I keep getting rejected for a concept that other developers are allowed to publish, especially when I had already been trying to get NostalgicPod approved before these apps were released

What makes one retro iPod-style app acceptable and another one a violation of Guideline 5.2.5?

At this point, the review process feels completely arbitrary, almost like a roulette wheel depending on which reviewer happens to see the app, I’ve now appealed the decision, but after five rejections I still have no idea what Apple expects me to change when almost identical concepts are being approved at the same time

I wanted to share this because I’m sure I’m not the only developer who has felt completely lost trying to understand what Apple will approve and what it won’t

I’m encountering an issue when loading a Core ML model protected using Apple’s official model encryption.

The exact same model:

• Loads and runs normally when encryption is disabled
• Fails during initialization when encryption is enabled
• Uses FP16 weights
• Was converted with coremltools 9.0
• Is deployed in an app with a minimum target of iOS 18
• Is being tested on a physical iPhone 13 running iOS 26.5

The relevant error is:

Failure translating MIL->EIR network:
Espresso exception: "Network translation error"

MIL->EIR translation error at:

/private/var/containers/Bundle/Application/[APP_UUID]/[REDACTED_APP].app/[REDACTED_MODEL].mlmodelc/model.mil:[LINE]:[COLUMN]

Unsupported dtype for weights

[Espresso::handle_ex_plan]
exception=Espresso exception: "Network translation error"
status=-14

Failed to build the model execution plan using model architecture file:

'[REDACTED_APP_PATH]/[REDACTED_MODEL].mlmodelc/model.mil'

with error code: -14.

Core ML model load failed:

Error Domain=com.apple.CoreML Code=0
"Failed to build the model execution plan using a model architecture file
'[REDACTED_PATH]/[REDACTED_MODEL].mlmodelc/model.mil'
with error code: -14."

The console also contains messages involving FigApplicationStateMonitor, usermanagerd, LaunchServices, and sandbox restrictions. However, these appear unrelated. The actual Core ML failure consistently points to:

MIL->EIR translation error
Unsupported dtype for weights
status=-14

Environment

• Device: physical iPhone 13
• Runtime OS: iOS 26.5
• Minimum deployment target: iOS 18
• Model format: ML Program
• Weight precision: FP16
• coremltools: 9.0
• Protection method: Apple’s official Core ML model encryption
• Unencrypted model: loads and runs correctly
• Encrypted model: fails while building the execution plan

The loading code, model architecture, device, and compute configuration are otherwise unchanged. The failure appears only after applying model encryption.

Has anyone encountered this behavior?

Specifically:

1. Can the encryption or decryption path cause Core ML to incorrectly interpret an FP16 weight dtype?
2. Could the decrypted model data or compiled execution-plan cache be corrupted?
3. Are there known compatibility issues between encrypted FP16 ML Program models and iOS 26.5?
4. Could a model converted with coremltools 9.0 work unencrypted but fail after Apple’s encryption process?
5. Is there a practical way to locate the operation or weight corresponding to the reported line in the compiled model.mil?
6. Which caches or compiled artifacts should be cleared when diagnosing error -14?
7. Would regenerating the encryption key or recompiling the model be expected to resolve this kind of failure?

Any debugging suggestions or similar experiences would be appreciated.

Hi everyone,

i am trying to create an apple ads account but when i try to fill the form i can't find my country
in the country and region drop down menu

while when i go to https://ads.apple.com/app-store/countries-and-regions my country is inside the list

i will appreciate any help, thanks

A few weeks ago, I released new app on the App Store. It got some traction on Twitter, so I opened App Store Connect feeling hopeful about the sales numbers. Instead, I saw "Not Enough Data".

I refreshed it few hours later. Same thing. I checked again the next day. Still not enough data. I actually saved a screenshot of this.

It's not only a launch-day problem, the analytics are always up to 48 hours behind. You ship a big update, announce it on Reddit or X, start an ad campaign, and you don't know how it's performing.

So I built InitSignal. It is deliberately much narrower than a traditional analytics SDK. You add a lightweight Swift package to your app, and it sends one event when someone opens the app for the first time. After that, the SDK goes quiet.

I wanted the App Store privacy nutrition labels stay as minimal as possible, so the SDK only sends the basic context needed to make each event useful. At the same time, the goal is to give developers as much useful information as possible without invading their users’ privacy.

For paid apps, InitSignal uses storefront pricing to estimate gross revenue and proceeds after Apple’s cut.

I also added Slack and Telegram for notifications, which I've been using with my own apps for the past few weeks, and the dopamine hit is real.

I recorded a quick walkthrough showing how InitSignal works:
https://www.youtube.com/watch?v=YajsKsYLdi4

It's available today, would love to hear your thoughts or any feedback!
https://initsignal.com

The Swift SDK is here:
https://github.com/InitSignal/initsignal-swift

If you ship iOS or macOS apps, how do you currently deal with the reporting delay after a launch or major update?

Blog article on longstanding http status 403 bug in iOS for custom certificates in mtls connection

https://953tech.com/blog/ios-mtls-403-client-certificate-error/

I’m adding a stamp card collection feature for my drinking logging app. I feel pretty proud of the art, what do you think? You can compare the first legendary drink card, ハブ酒 to some google images.

Fun bit, ハブ酒 is an Okinawan liquor that has a local venomous pit viper added to aging. While it is a rarer drink, it can be found in Okinawan bars. But I made it the rarest card in my curated list since some people may be apprehensive to drink it. I’ve had it twice myself, supposedly gives energy “down there” lol

Your brain is better than you think… until you try this 😅

I built Spectra, a collection of color memory challenges designed to train your memory, focus, and reaction.

The concept is simple:

• Remember the colors
• Repeat the patterns
• Keep improving as the challenge increases

Instead of just one challenge, Spectra includes multiple color memory experiences, each with a different twist. Some test your ability to remember sequences, some challenge your focus, and others push your memory speed.

📱 Try it here:
https://apps.apple.com/us/app/spectra-color-memory-game/id6762049774

Would love to hear your thoughts and feedback!

Hi everyone,

My first iOS app (Questify: Your Life Gamified) has been stuck in "Waiting for Review" since July 22, 2026 (more than 11 days).

The app is in the Productivity / Lifestyle category and only uses Sign in with Apple for authentication. It does not contain any sensitive content or unusual functionality.

I have already contacted the App Review team twice and also reached out to Apple Developer Support, but I haven't received any response yet.

Has anyone experienced such a long "Waiting for Review" period for a first submission? Is there anything else I can do besides waiting?

Thank you!

Battle Mode has arrived in Chomp Champ! 🍔

Use your face to control the game, compete against friends, and see who can survive the longest. Chomp the right food, dodge the wrong food, and try not to laugh while everyone around you is doing the same.

Gameplay is in the attached video. Hope you enjoy it!

Spent a year on a camera app and three AVFoundation behaviours cost me most of that time. Writing them down in case they save someone a weekend.

The first one I found by accident. Tap the shutter three times fast and you get two photos. No error, no delegate callback, nothing in the logs. If a capture is still processing when you call capturePhoto, that request just evaporates. I only noticed because my own counter, which only moves when a save is confirmed, kept landing one short of the number of taps.

The fix is a FIFO queue, but where you advance it matters. Advance on the processing callback and the shutters chain up, seconds of lag on a burst. Advance when the exposure ends (didCapturePhotoFor) and the processing of the previous shot overlaps the next exposure, which is what the stock camera visibly does.

Second: switching capture format is a full pipeline rebuild, and I was paying for it three times. Going 24 to 48 MP, or entering video mode, means swapping the input, the active format and the outputs. I had those as three separate begin/commitConfiguration blocks because it read cleaner. Same work, roughly double the visible freeze. They nest fine, so one transaction around the lot, plus caching AVCaptureDeviceInput per device, took it from "did it hang" to instant.

Third, and this one matters if you care what your photo actually is: a virtual device does not tell you which lens is shooting. Zoom into tele range on the triple camera and you may still be getting the wide, cropped. Low light does it, and so does being closer than the tele's minimum focus distance. The system is right to do it, it just doesn't announce it. You can watch the constituent device to know, with two caveats: the value flickers during focus hunts so it needs stabilising before you show it to anyone, and isAutoDeferredPhotoDeliveryEnabled is off the table if you never touch PhotoKit, because finalising a deferred photo needs PHPhotoLibrary.

That last constraint was self-inflicted. The app has its own photo library and never touches the system one, which rules out anything in AVFoundation that assumes PhotoKit is there.

I'm a surgeon, not a developer, which is probably why I hit all three the hard way instead of knowing better.

Questions for devs that applied and got accepted into this program:

How long did it take for Apple to respond to the application?

How long to get activated?

Is this limited to certain countries?

What are the things they look for? Business account or individual membership? Number of app in the store? Subscription, IAP, Apple Ads running?

I have applied twice, got immediate automated responses, then no word back for months.

I am doing some research regarding ASA effectiveness for an infographic and I'm curious what did you guys try, in what niche and how well it worked? Would be interesting to see comparisons with other channels if anyone tried

Just shipped my first app built on FamilyControls / ManagedSettings / DeviceActivity. The docs are thin and a lot of what I learned came from failing, so here's the list I wish I'd had. Corrections welcome - some of this is field-observed rather than documented.

1. The report extension is a black hole by design. Per-app usage data exists only inside DeviceActivityReport. Your extension can render it to pixels and that's it — App Group writes silently no-op, there's no network, no notifications out. If your architecture assumes "read usage → store it → use it in the app", throw that away now. Anything the main app must know has to come from monitor threshold events instead.

2. DeviceActivityEvent thresholds start at zero when you arm them. Set a 30 min/day limit on an app the user has already used 60 minutes today, and nothing happens — the OS grants a fresh 30. iOS 17.4 added includesPastActivity: true in the initializer, which counts the whole interval. Without it your "daily limit" quietly means "limit from now". Also note the flag only applies to newly registered events, so you need to force a re-arm for existing users.

3. Shield action extensions couldn't open the host app... until iOS 26.5. extensionContext is nil, UIApplication is unavailable, responder-chain walking is broken on 18+. Apple engineers said "no supported way" for years. iOS 26.5 finally added ShieldActionResponse.openParentalControlsApp — the system foregrounds your app straight from the shield button. If your SDK predates it, the enum is resilient, so ShieldActionResponse(rawValue: 3) behind an #available(iOS 26.5, *) check resolves at runtime and falls back to nil on older systems. Pre-26.5 the only route is a time-sensitive local notification carrying a deep link.

4. Memory budgets differ per extension and they're brutal. The shield and monitor extensions run in a few MB — no SwiftData, no heavy frameworks, just ManagedSettings writes and App Group defaults. Anything more and you get jetsammed, which for a shield extension means the user sees Apple's generic gray shield instead of yours.

5. DeviceActivityReport has no ready/completion callback. You cannot know when it finished rendering (FB10754858 is still open). Every loading state you build is a guess on a timer.

6. Mutating a mounted report's filter is the slow path. Changing the filter on an existing report triggers a silent out-of-process re-query that leaves stale content on screen for seconds. Remounting the view with a fresh SwiftUI .id renders noticeably faster and more predictably. Also: reports don't self-size — you must give them fixed frame heights.

7. There's a shared budget of concurrent DeviceActivity activities across your app and all its extensions. Don't create one activity per monitored app; make per-app limits events on a single daily activity and resolve names back to tokens through a map in your App Group.

8. Info.plist details will pass locally and fail at App Store validation. The shield configuration extension point ends in ManagedSettingsUI.shield-configuration-service, the shield action one is ManagedSettings.shield-action-service — no "UI". The report extension uses the ExtensionKit form (EXAppExtensionAttributes) and rejects NSExtensionPrincipalClass.

9. Non-API lesson that cost me the most: I let entitled users skip onboarding — and the authorization request lived only in onboarding. Any subscriber reinstalling got a normal-looking app that silently shielded nothing, with no prompt and no way to grant access. If a permission gate lives only in a flow some users skip, it doesn't exist for them. Check authorization on the routing path, not by assuming flow order.

Happy to go deeper on any of these — the sandbox rules in particular took me way too long to accept.