Apple and Google sign-in are not a nice-to-have — they are the hidden gate between “works on my phone” and “live on the App Store or Google Play.” Here is why that week always eats your roadmap.
Every mobile team has the same calendar. Monday: polish the onboarding animation. Tuesday: fix the one crash that only happens on a physical iPhone 12 in low power mode — or an Android OEM skin you have never heard of. Wednesday: realize you still do not have Sign in with Apple wired up correctly, and Google OAuth is returning a redirect URI mismatch that only reproduces in TestFlight or an internal Play track.
Thursday is screenshots. Friday is prayer — whether you are waiting on App Review or Google Play's slower, quieter queue.
This is not a failure of engineering. It is what happens when the last mile of shipping is not your app — it is identity plumbing that Apple and Google treat as production infrastructure, not a weekend library install.
On iOS, if your app offers Google sign-in (or Facebook, or any third-party login), Apple's guidelines expect Sign in with Apple on the same screen, with equal prominence. Reviewers notice. Users notice. Your “we'll add Apple next sprint” backlog item becomes a binary gate: approve or reject.
On Android, Google Play's policies push you toward Google sign-in when you use social or third-party identity — and users expect it anyway. That means OAuth clients, consent screens, SHA-1 and SHA-256 fingerprints for release builds, package names, and keystore aliases that all agree with what you uploaded. Internal testing tracks are unforgiving: debug builds lie; signed APKs and AABs tell the truth.
Google is symmetric on both stores in a different way: Play Console and web flows want OAuth clients split by platform when you are on Expo or Capacitor — and they are easy to mix up. One typo in a redirect URI and auth works in the emulator, fails in the build reviewers install.
So you are not choosing “add auth.” You are choosing two vendors, two consoles, two token shapes, and a session story that survives background refresh, account deletion, and the reviewer tapping “Hide My Email” or signing in on a phone that has never seen your dev build before.
Teams routinely budget a few days for “social login.” The integration tweet shows a button and a JWT. The real work is everything around it:
That work does not show up in the changelog. It shows up as a week where the feature you wanted to ship — the one users will pay for — sits behind a configuration screen with forty fields and no undo button.
Kembo exists because the unglamorous path to App Store and Play Store week should not require becoming an OAuth consultant. The product decision was simple: let a solo dev or a small team get Google and Apple on the same screen, with hosted OAuth on the free tier, before anyone has opened Google Cloud Console.
You create a project, pick Expo or Flutter or Capacitor or Web, paste an agent prompt or follow the manual steps, and sign in on a real device — iOS and Android. Kembo hosts the redirects. Sessions get refresh rotation and hashed storage — the parts you would otherwise cargo-cult from three blog posts written in 2021.
When you are actually ready for the stores — not “demo ready,” review ready — you upgrade that project to Pro. Your app name and logo on the sign-in screen. Your Google and Apple credentials if you want them under your developer account. Production mode. The same SDK hooks; the branding and OAuth ownership change, not your navigation graph.
Picture the alternative timeline. Auth already worked last month on both platforms. This week you are:
That is what “fast shipment” means in practice — not skipping auth, but not discovering auth on the critical path. The teams that feel lucky on launch week are not faster coders. They front-loaded the unsexy requirement Apple and Google already wrote for them.
We are not trying to be your entire backend, your analytics suite, or your push notification vendor. Kembo is narrow: mobile-first sign-in, sessions, optional privacy-first analytics when you opt in on Pro.
That narrowness is the point. Neither store rejects you for lacking a feature flag system. They reject or stall you when Sign in with Apple is missing, broken, or buried — when your Google flow opens a web view that feels like a phishing test — or when Play's signed build cannot complete OAuth because the fingerprint in Cloud Console is still the debug one.
The best feedback we get is not “auth was easy.” It is “we forgot auth was there.” The dashboard shows real users. You configure branding once. You move on to the thing that makes your app worth installing — on both stores.
If you are staring at a Wednesday calendar block that just says “OAuth,” that is not a you problem. It is an industry pattern. The fix is to treat Google and Apple sign-in like CI or crash reporting — infrastructure you plug in early, not a surprise tax the night before you hit Submit on App Store Connect or roll out to production on Play.
Start a free project, sign in on a device this week, and save launch week for the work only you can do.