App Store submission, and the note that comes back

What we take through review

We start from an installable build, or from a review message you already have. We complete App Store Connect, upload the binary, and write notes a reviewer can follow alone. When an app is rejected by Apple, the message cites App Store review guidelines. We reply in the thread for an explanation, and upload a new build for a defect. Approval stays with the store.

Requests we can price from a message

For a first release, bring age-rating and export answers you will stand behind. For a rejection, send the message and the build number. Typical stops: sign-in blocked by an email code, an invite, or an empty workspace; a crash on the named device; a screenshot of a missing control; a sandbox purchase or restore that never finishes; no account deletion; privacy answers that disagree with the libraries; a vague permission prompt; or the app called a website in a frame.

Code fixes stay in the repository's stack: Swift and SwiftUI, Kotlin and Jetpack Compose, or React Native or Flutter. For Play, name the track and whether the graphics exist.

From the first email to handoff

Tell us first release or rejection, and whether Play is included. Do not email passwords.

A message we can already read, on a project that archives, is hourly. The upload, the listing, TestFlight, and one round of notes is a fixed-price project. If nothing archives, paid discovery comes first, and you keep the write-up if you stop.

Your company holds the Apple Developer membership and, for Android, the Play Console. You invite us to upload, then remove us. Keys and the repository stay yours. We take few projects at a time, so you write to the person doing the submission and leave with a release you start yourself.

Connect, TestFlight, and the listing

The Apple tools are Xcode, App Store Connect, and TestFlight. Review notes carry a working login and the on-screen path. StoreKit goes out with the version, after a sandbox purchase, a restore, and a failed payment. A widget, a Safari extension, or Apple TV is listed only if this binary has it.

App store optimization here is the listing: name, subtitle, keywords the name left unused, and screenshots from the release candidate. Another language needs its own strings and images. We fill privacy questions from what the app and its libraries send, plus the Play testing track, content rating, data-safety form, and each permission line. We do not certify compliance or advise you on the payment rule. A disputed charge follows the model you already chose.

Who should email

Email when the build runs and submission is the gap. An owner whose developer stopped at the archive. A marketer with the screenshots. An agency placing the launch as a sub-project, under its name or with hehe.software credited.

Search placement, a legal opinion, a site wrapped as an install, and an empty repository are outside this work. hehe.software is a small, independent studio based in Vancouver, British Columbia, working remotely with businesses across Canada and the United States.

Nine submissions of our own

Our proof includes nine apps we designed, submitted and maintain ourselves. Rain is an iPhone and iPad browser; Tifo also targets Apple TV; Moonflower includes a Safari extension. Their releases involve different binaries, listing assets and review paths. They are owned products. For your submission, the useful deliverable is a working release candidate, accurate metadata and review notes someone can follow.

Across them: Swift and SwiftUI, a Safari Web Extension, StoreKit, Home Screen widgets, and offline SQLite. The SNAAAAKE listing honors Reduce Motion and has VoiceOver menus.

• An Apple team invite, and Play Console access if Android is included.
• The repository or a signed archive, and who holds the keys.
• A support address, a privacy-policy address, and a signed-out demo login.
• The review message and its build number, if you have one.
• What the app charges for, and whether that purchase is used in the app.