iOS
3 Areas to Check When Profiling SwiftUI Performance
View updates, stable collection identity and the cost of creating views — three areas to investigate with profiling tools.
Aleksander Pavlov27 Sept 20261 min read
App Store Review Checklist: Five Areas to Check Before Submission
Serg Bogatenko27 September 20262 min readUpdated
Preparing an iOS release means checking the complete experience: the build, account access, backend, purchases and submission information. Use this checklist to organise a technical review, then check Apple’s current requirements for your app. Approval remains Apple’s decision.
Five Areas to Check Before Submission
| Area | What to check |
|---|---|
| Login | Assess whether Guideline 4.8 applies to your login flow and whether an exception is relevant. |
| Permissions | Check that requested access matches the feature and that the purpose is explained clearly. |
| Purchases | Review the applicable rules for your product type, storefronts and entitlements. |
| Build and metadata | Remove incomplete content and broken links; check that descriptions and screenshots match the build. |
| Review access | Provide working access, available backend services and clear instructions for restricted features. |
Run a Review Rehearsal
Ask someone who did not implement the feature to follow your review instructions using the release candidate.
Can they reach the important screens without asking the developer for help? Do the supplied credentials work? Does the account contain the data needed to understand the feature?
Record each blocker and assign an owner before submission. This rehearsal is also a useful handover between mobile, backend and product teams.
Example: An App With Restricted Account Access
Prepare a short internal note containing:
- The feature the reviewer needs to assess.
- The steps required to reach it.
- The expected result.
- Any account role, sample data or hardware dependency.
- The person responsible for keeping access available.
Use a dedicated review account rather than a real customer’s account.
Already Received a Rejection?
Start with the specific issue described in the review message. Reproduce the reported journey using the submitted build and review account.
Separate the work into three categories: an application change, a backend or configuration change, and a clarification in the submission information. Assign responsibility for each item and verify the complete journey again before resubmitting.
Related Development Work
Explore Skinner, where Sparkler Soft developed the native iOS application and integrated an external AI analysis API.
Explore the Skinner iOS and AI Integration Case Study →SB
Serg Bogatenko
Senior iOS Developer
Serg is a senior iOS developer at Sparkler Soft, writing about native application development and release preparation.
LinkedIn →Related Articles
Need Help Preparing a Release or Resolving a Review Issue?
We can help investigate a defined iOS issue, check the app’s connection with backend services, or implement an agreed fix. To start, describe the affected feature, your release stage and the help you need. If you have a review message, you can share it after removing credentials and customer information.