Why iAsk needed a mobile app
Mobile web didn't feel native or fast enough, and competitors were already in the App Store.
iAsk had a mature web product, but mobile web didn't feel native, fast, or focused enough for something people would reach for often. Search through a browser tab is a worse experience than an app that opens straight into it. At the same time, competitors already had a presence in the App Store. Leadership decided iOS needed to happen; the call came from the CEO, and the project landed on my desk as the sole designer on it.
Moving the search bar to the bottom of the screen
The web version puts the search input in the middle of the screen. On iOS, I moved it to the bottom, closer to where a thumb naturally rests, cutting the reach needed for what would be a frequent, repeated action rather than a one-off. Small decision, but it's the difference between an app that feels native and one that feels like the website wrapped in a shell.
Getting through Apple's own review process was its own real constraint, down to specifics like exact preview-screenshot sizes required for every device the listing needed to support. None of it is design work in the usual sense, but all of it had to be planned for before V1 could ship at all.
What V2 added after V1
V1 shipped with one thing, the core search. V2 added the rest once that held up.
Rather than porting every web feature to iOS at once, V1 shipped with exactly one thing: the core search experience. No login, no subscription, no history. Just the fastest way to find out whether people actually wanted iAsk as a native app before investing in everything else. V2 followed once that held up, adding sign-up and login, search history, settings, follow-up search, and the Pro subscription.
Designing a subscription screen without in-app purchase
No purchase inside the app. Buying meant leaving iAsk for the web, and some people wouldn't come back.
By the time V2 added the Pro subscription, one constraint was already decided above me: no purchase inside the app. Apple takes a cut of in-app purchases, and the business chose to avoid it, so buying a subscription meant leaving iAsk entirely. That's a real risk: send someone to a browser mid-decision, and there's a good chance they don't come back.
A value screen before the handoff: what the person would get, shown before they were sent anywhere, so the redirect had a reason attached to it instead of reading as a dead end.
The redirect itself, out to the web for the actual payment. This was the one piece of the flow I didn't choose: it was decided above me, for cost reasons.
A deep link back into the app after payment, landing on a subscription that was already active. That closes the loop instead of leaving it to guesswork.
Results
10K+ downloads in the first 90 days, mostly existing web users moving to the app, not new people finding iAsk.
V2 turned iAsk iOS into something people opened again: search history, settings and an active subscription gave people a reason to come back instead of using it once and reverting to the browser. The growth side is more mixed, and worth stating plainly: the goal was a new acquisition channel, and the app did cross 10,000 downloads in its first 90 days, but most of that was existing web users moving to a native option rather than people finding iAsk for the first time. The goal was broader than what happened. It is a more honest result than dressing it up as pure growth, and still a real one.