What I keep seeing: the permission prompt on first launch, "We miss you!" copy, everyone blasted at 10am server time. Then everyone's surprised when opt-outs climb.

I wrote a practical playbook on the opposite approach: ask after a real win, give every push a reason that belongs to the reader, send at each user's own active hour, and cap nudges at about 1 a week.

https://medium.com/@krishnassss365/push-notifications-that-earn-their-place-cb1e85a46a85?sharedUserId=krishnassss365

Curious what's worked for you. Has anyone measured opt-out rate per message instead of open rate?

Anyone know how to get an account for a business email? I keep getting account cannot be created at this time and the developer.apple.com support for creating an account requires an account, same with the contact form or phone support. Using my personal apple account is not an option.

EDIT: I had to call the consumer help line and they redirected me.

A while ago I asked here what you consider when building an app. Since then I shipped two big updates of my running app for Apple Watch and iPhone, and turned what I learned into a checklist.

It’s not a list of things you must support. It’s things you should consciously decide on, yes or no, before they surprise you:

• Screen sizes (smallest device + longest realistic values)
• Rotation
• Dynamic Type / text size
• iPad, Mac, Vision Pro
• Multiple windows
• Accessibility (VoiceOver, colour as the only signal)
• Live Activities (and how often they really need to update)
• Widgets (sizes and families)
• Complications
• App Intents / Siri / Shortcuts
• Sharing (what goes out, what comes in)
• New device classes coming up
• Gestures (Double Tap, Digital Crown, conflicts with the system)
• Action Button
• Translation (every future feature in every language)
• Animations and Reduce Motion
• Older devices: speed and battery
• iCloud: backup or sync?
• Light and dark mode

Tip: write down every answer, including the no’s and why. And this is iOS/watchOS only. Add Android, tablets or desktop and the list roughly doubles.

Longer version with my reasoning for each point, plus an interactive checklist you can export as Markdown: The list behind every app

Two questions:

1. What’s missing? What bit you the hardest?
2. English isn’t my first language. I wrote the post in German and translated it with AI. Does it read AI-ish? What gives it away?

I wrote a technical walkthrough of a subtle Swift Concurrency issue I wanted to explore.

Imagine a task writing data into a buffered writer. The task gets cancelled, defer runs, and close() gets called. But if close()invokes a cancellation-aware flush(), that flush can throw CancellationError. If the error is swallowed and the writer is marked closed anyway, the cleanup path has run without achieving its intended postcondition.

The article explores two Swift Evolution proposals:

• SE-0493: Async calls in defer bodies
• SE-0504: Task Cancellation Shields

It covers a minimal reproduction, the limits of using Task.detached for cleanup, a narrowly scoped cancellation shield, and a Swift Testing example that checks whether the data was actually flushed rather than merely checking whether close() was called.

One important caveat: the example demonstrates a cancellation-aware cleanup failure, not a claim that every real file API corrupts data when cancelled.

Full article: https://sagarsaurav.medium.com/the-ios-task-was-cancelled-your-defer-still-didnt-flush-the-file-a81d45b02ad9?sharedUserId=sagarsaurav

I'd be interested in feedback on the cancellation-shield approach, especially around resource ownership and cleanup guarantees in production code.