How do you keep web and native at parity?

Whatever your reason for going native, here is the rule that saves you: you must keep your web and your native versions at parity, and the only sane way to do that is to start from the very beginning.

I always knew I wanted HVNG to be for everyone, on everything, so I built this intention into my very first foundational prompt — the same architecture brief from Section One. Cross-platform was not an afterthought I tried to bolt on at the end. It was a requirement from the first sentence.

But here is the warning, and it is one of the most important behavioural truths about building this way. The AI will always drift. Over many iterations, it will quietly let your platforms fall out of sync, adding a function to the web that never made it to native, or the reverse. So you must remind it, regularly and deliberately, to maintain parity, and to ensure that every function is accessible from any platform. Make it a standing instruction you repeat, not a thing you said once and trusted forever.

Parity is not a state you reach. It is a discipline you maintain, because the AI's natural tendency is to drift apart. Say "keep web and native at parity, all functions on all platforms" again and again.

How to test your app on a real iPhone

So how do you actually see your app on a phone? For iOS, you start with a free tool called Expo Go.

You download Expo Go onto your phone, and then Claude can generate a link that lets you load the app locally and play with it on your actual device. The one catch to remember is that your phone and your laptop have to be sharing the same network for this to work, because the phone is reaching across to the project running on your machine.

The instruction could not be simpler: just ask Claude to provide you an Expo Go URL to test the platform with, and go and tap around your own creation on your own phone. It is a genuinely magical moment the first time.

TestFlight and the developer accounts

Expo Go is for playing and testing during development. The next step — for the full, proper iOS experience and for letting other people test a real installed build — is TestFlight, which is Apple's official beta-testing system.

To use it, you have to register as an Apple Developer. This costs about ninety-nine US dollars a year. (I once had the figure of around fifty thousand naira in my head, but with where the exchange rate has gone, ninety-nine dollars is more than that today, so do not be caught out — check Apple's current local price for Nigeria before you budget for it.) It is a recurring annual fee, so factor that in.

Android is far gentler on the wallet. The Google Play developer registration is a one-time charge of about twenty-five dollars, paid once in your life, and you are in. No annual renewal. So if cost is a worry when you are starting, know that getting onto Android is cheap and permanent, while iOS is the one with the yearly rent.

Budget for the platforms honestly and early. Android is a small one-off. iOS is a yearly subscription to Apple. Neither is a fortune, but knowing the numbers up front means no nasty surprise the week you are ready to launch.

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G10.1 · Keep web and native at parity (a prompting checklist) [Core if native]

What you'll have: Web and native versions staying in sync from one codebase.

Before you start: Beginner · ongoing · free · you'll need a cross-platform setup (React)

1. Put cross-platform parity in your original architecture brief (G1.1).
2. Regularly remind Claude: "keep web and native at parity; every function accessible on all platforms."
3. After each big feature, ask Claude to confirm parity across web, iOS, and Android.

Check you did it right: A new feature appears on every platform.

If something looks off: Drift (a feature on web but not native) → prompt the fix; this recurs, so make it a habit.

G10.2 · Test on your iPhone with Expo Go [Core if native]

What you'll have: Seeing your app on a real phone during development.

Before you start: Beginner · ~20 min · free · you'll need an iPhone on the same wifi as your laptop

1. Install Expo Go on your phone from the App Store.
2. Ask Claude to provide an Expo Go URL or QR to load your app.
3. Make sure your phone and laptop share the same network.
4. Open the link or scan to run the app locally on your phone.

Check you did it right: Your app runs on your phone.

If something looks off: Won't connect → confirm the same wifi and restart the dev server (ask Claude).

G10.3 · Set up an Apple Developer account and TestFlight [Core if native]

What you'll have: A proper installable iOS build for you and your testers.

Before you start: Intermediate · 1–2 hrs plus Apple review · ~$99/year (check the local naira price) · you'll need an Apple ID

1. Enrol in the Apple Developer Program (about $99 a year; the naira equivalent moves with the exchange rate, so check current).
2. Set up your app in App Store Connect.
3. Have Claude or Expo build an iOS build and upload it to TestFlight.
4. Invite testers.

Check you did it right: Testers install your app via TestFlight.

If something looks off: Build or signing errors → paste them to Claude; Expo has docs and help too.

G10.4 · Set up a Google Play developer account [Core if native]

What you'll have: The cheaper path onto Android.

Before you start: Beginner–Intermediate · ~1 hr · ~$25 one-time · you'll need a Google account

1. Register for a Google Play developer account (about $25, one-time, for life).
2. Create your app listing in the Play Console.
3. Have Claude or Expo produce an Android build and upload it for testing or release.

Check you did it right: Your app is in the Play Console, ready for internal or closed testing.

If something looks off: Listing requirements → fill the required fields and use the Console's help.

G10.5 · Publish to the app stores [Core if native]

What you'll have: Your app live and downloadable by the public.

Before you start: Intermediate · review time varies · covered by the G10.3 / G10.4 fees · you'll need builds and store listings

1. Complete your store listings: name, description, screenshots, privacy details.
2. Submit iOS for App Review and Android for review.
3. Address any reviewer feedback (paste it to Claude).
4. Release.

Check you did it right: People can find and download your app.

If something looks off: Rejections → read the reason, fix it, resubmit; this is common and normal.

One build, everywhere, and the end of the technical road

So there it is, the bonus that was never really a bonus. One codebase, kept at parity by discipline, tested on a real phone through Expo Go, and shipped to the world through the app stores once you have paid your dues to Apple and Google.

And with that, the technical road of this manual reaches its end. Stop and look at how far it runs: from a sentence in your head, to a prototype, to a live site, to open doors, to a tested and optimised product, to a thing people love, to a thing that earns, to a thing the machines can find, and now to an app sitting on phones in pockets across the city. Every single step taken by a non-coder who simply learned to articulate what he wanted, clearly, to a patient machine.

Afterword: the road to Book Two

That is the technical manual, chapters and labs together, end to end. From a sentence in your head to an app in pockets across the city, every step taken by someone who learned that articulating logic clearly to a patient machine is a skill you already half-possess if you can tell a story.

But a built thing, however beautiful and native and discoverable, still has to meet the world. It has to be launched. It has to be marketed. It has to be branded into something people feel a pull toward. And those are big enough, and different enough, to deserve their own book. So that is exactly where they are going: into a second, companion manual, Book Two — Launch, Marketing, and Branding, kept separate from this one so each can be what it is without diluting the other.

The invitation, for the last time in this manual, does not change. You did not get to the app store alone, and you will not conquer the market alone either. Africa moves as an ecosystem or it moves slowly. We share hosting, we share tokens, we share the tools and the hard-won numbers — like which developer account costs what — so nobody gets ambushed.

Come build with us at AIStoryLab. Twenty thousand naira a year, still too cheap. Bring what you have learned, take what you need, and let us turn a generation of dreamers into a generation of shippers.

This is the end of the technical manual. The business of being seen begins in the next one.