Push notifications are a permission, delivery and relevance problem. Ask at the right moment, explain the value, segment the audience and measure whether notifications are opened or muted.
Key takeaways
- SwiftUI is the default for new interfaces; UIKit is still common in existing apps and advanced controls.
- iOS uses APNs; Android uses FCM. Cross-platform tools abstract the transport but not the permission UX.
- Ask for permission after the user has seen the value, not on first launch.
- Plan the store submission and first year of maintenance before you start building.
What changes with Swift + SwiftUI/UIKit
- SwiftUI is the default for new interfaces; UIKit is still common in existing apps and advanced controls.
- Xcode, signing, TestFlight and App Store Connect are part of the delivery workflow.
- Keychain, App Transport Security and privacy manifests are core security and review requirements.
- A Swift-only product needs a separate Android decision; do not assume cross-platform reach.
Build and release path for Swift + SwiftUI/UIKit
| Stage | What happens | What to check |
|---|---|---|
| Build | Xcode archives the app and manages signing | Use automatic signing only with a clear team setup |
| Testing | TestFlight provides internal and external beta builds | External review adds time |
| Privacy | Privacy manifest and required-reason APIs must be accurate | Missing declarations can block review |
| Store | App Store Connect holds metadata, pricing and releases | Keep the account and agreements in your name |
What the work actually requires
- Deep links should open the right screen and handle a cold start.
- Delivery is not guaranteed; design for missed notifications and a visible in-app inbox.
A practical plan
- Define the events. Order updates, messages, reminders, promotions — and who can opt out.
- Design the permission moment. Explain the value and ask after the first meaningful action.
- Register the device. Store the token, platform, user and opt-in state.
- Send through a queue. Handle retries, invalid tokens and rate limits.
- Deep link. Test warm and cold starts, logged-out users and missing content.
- Measure. Delivery, open, opt-out and uninstall signals.
Decision guide
| Area | What to check | Why it matters |
|---|---|---|
| Permission | iOS/Android prompts | Ask after value, not at launch |
| Transport | APNs/FCM | Validate tokens and handle failures |
| Targeting | Segments and topics | Do not spam the whole base |
| Deep links | Warm/cold start | Test logged-out and missing content |
| Reliability | Retries and queue | Delivery is best-effort |
| Measurement | Open and opt-out | Track fatigue, not just sends |
Platform rules to check
- Apple: privacy manifest, permission purpose strings, in-app purchase rules and review guidelines.
- Google: data safety form, permissions, target API level and Play policy.
- Both: account deletion, privacy policy, accessibility and accurate store metadata.
First-year budget for Swift + SwiftUI/UIKit
| Line | What it covers | When it lands |
|---|---|---|
| Discovery and design | Journey, prototype and UI system | Before build |
| App build | Screens, state, API integration and tests | Main build phase |
| Backend/admin | API, database, roles and reporting | Alongside the app |
| Integrations | Payments, push, maps, analytics | Mid-build |
| Store launch | Assets, review, signing and release | At the end |
| Maintenance | OS updates, dependencies and fixes | Every year |
Launch checklist
- A test build signed with the production key, installed on a clean device.
- Account creation, login, logout and account deletion all work.
- Push notifications, deep links and offline states have been tested.
- Privacy policy, store data disclosure and permission text match the app.
- Screenshots, description and support URL are accurate and localised where needed.
- Crash reporting and analytics are live before the first release.
Store review risks for Swift + SwiftUI/UIKit
| Risk | Why it happens | How to reduce it |
|---|---|---|
| Missing privacy details | SDK data use is not disclosed | Audit SDKs and complete the forms |
| Broken demo account | Reviewer cannot sign in | Provide a working test account |
| Payments rule | Digital goods bypass in-app purchase | Use the required store billing |
| Minimum functionality | The app is only a website wrapper | Add real native value |
| Misleading metadata | Screenshots or claims do not match | Show the real product |
Post-launch metrics for Swift + SwiftUI/UIKit
- Swift + SwiftUI/UIKit: crash-free sessions and the top crash groups for this release.
- Activation: the user completes the first meaningful action.
- Retention: return rate after one day, seven days and thirty days.
- Store conversion: page views to installs.
- Support contacts per hundred active users.
- Release adoption after an update.
Common mistakes
- Choosing a stack before defining the core user journey.
- Estimating by screens instead of workflows, roles and integrations.
- Leaving store submission, analytics and maintenance out of the budget.
- Testing only on a fast simulator instead of a mid-range real device.
- Treating the client as trusted for prices, roles or business rules.
Frequently asked questions
No. Push is best-effort. Use an in-app inbox or email for critical messages and handle missed notifications gracefully.
After the user has completed a meaningful action and understands the value. A pre-permission screen can explain the benefit before the system prompt.
Check the token, APNs/FCM configuration, environment (sandbox vs production), payload size, app state and user settings. Log the provider response.
Store the token separately from the user, clear it on logout if appropriate and deep-link to a safe screen. Do not leak another user's data.
Sources and further reading
- Swift documentation (swift.org)
- Apple Keychain Services (developer.apple.com)
- Apple App Transport Security (developer.apple.com)
- Apple privacy manifest files (developer.apple.com)
- Apple App Store Review Guidelines (developer.apple.com)
Related reading
Planning a mobile app?
Send the user journey, the platforms and the integrations. I will help you scope a realistic first release and a maintenance budget.
How to cite this guide: Nur Hossain Repon, “Swift push notifications: guide for founders”, Nhrepon Portfolio, reviewed October 2026, https://nhrepon.com/posts/swift-push-notifications-guide-for-founders.
Comments
No comments yet.