Apple approved Learn Hebrew – Read & Speak for the App Store in October 2026. For Viktor Sokoliuk, months of iOS work had finally become something iPhone users could install. Behind that release stood more than five years of product history on Android.
The idea had started much earlier, with a colleague who owned an iPhone and could not try the app. What began as a passing comment had become a second platform for a mature product.
AI tools helped make that native iOS client feasible for one indie developer. The founder also had a much older advantage: a functioning backend, learning content, and years of decisions about how the product should work. Even with those foundations, bringing it to another platform still took months.
What does it actually take to port a mature Android app to iOS when AI can help with the code?
This article draws on the founder’s account of the iOS project. The short quotation below is an editorial English translation from Russian.
An iPhone user plants the idea
There was no iOS plan at the beginning.
At a previous job, colleagues were talking about personal side projects. The founder mentioned his Hebrew-learning app. One colleague owned an iPhone and could not install it. Partly joking and partly serious, he said he was waiting for an iOS version.
It was a passing chat conversation. The founder also recalls that the colleague later seemed to bring it up again under a LinkedIn post about the app. Neither exchange immediately became a project. The idea simply stayed with him: why not?
For the next few years, time and the technical setup were missing. He was primarily an Android and Windows user, and maintaining the existing product already gave him work to do. An appealing possibility can remain on the edge of a developer’s attention for a long time without becoming something they can realistically build.
The colleague’s request mattered because it put a person behind the platform gap. Someone interested in the app could not even try it. A later observation about the Android audience gave that gap a business dimension.
Audience data makes the hardware purchase worthwhile
A large share of the Android app’s users were coming from the United States. The founder thought of it as a market where iPhones were common. That made remaining Android-only feel increasingly limiting: the product was already finding an audience there, while potential learners with another kind of phone remained outside it.
His own audience data was enough to move iOS from a colleague’s suggestion toward a product decision worth investing in. People in that market were already choosing the Android app; opening it to iPhone users became a more compelling use of development time.
One part of that investment was a used Mac, bought primarily for this project. It was not particularly cheap.
He had used Macs before and found them comfortable. His main computer had been a relatively powerful gaming laptop, deliberately chosen with plenty of performance headroom. Buying the Mac meant adding another real expense to a setup that already worked for his existing development.
For this iOS project, Apple’s development and shipping workflow made the Mac necessary. That cost belonged to the platform expansion just as much as the implementation work did. A promising audience did not remove the practical question of how one developer would build and deliver the app.
Five years of work behind a second client
The biggest technical advantage was the product infrastructure already in place.
The Android app had a working backend, an API, an administration panel, and existing learning content. It also had established product logic: years of choices about lessons, practice, progression, and how the learning areas fit together. Real use had given the founder years of iteration to draw on.
The iOS application could become a second client of that system. It needed its own implementation and interface, but the entire product infrastructure did not have to be invented again.
This changes the meaning of “building an iOS app.” A new product might require someone to develop the content, decide the learning model, build the tools for administering it, and establish the services behind the interface. Here, much of that work had already happened. The new client had a mature system to connect to and a product to express.
The earlier founder story explains how the app’s teaching philosophy developed. For the iOS port, the important consequence was practical: the founder already knew what he was trying to teach and had material built around those decisions.
That knowledge shortened some decisions and gave others a standard to meet. A screen could be judged against the learning experience it needed to support. An implementation could be judged against product behavior that already existed.
The iOS work inherited more than five years of product development. Describing it as a new app built from zero in a few months with AI would leave out most of its foundation.
For another indie developer considering a platform expansion, that is a useful place to begin the calculation: how much of the product already exists independently of its current mobile client?
What AI made possible
The earliest Android versions were built before modern AI coding agents existed. Even when AI tools began to appear, their usefulness was much more limited than it would become by the time of the iOS project.
The port happened in a different engineering environment. AI helped investigate technical approaches, evaluate the technology stack, and accelerate raw code implementation. It contributed to the decision to build the iOS app natively in Swift.
For the founder, this was a substantial change in what one developer could take on. A serious native client became far more achievable when implementation could move faster and technical possibilities could be investigated with assistance.
His view of AI as an engineering tool is strongly positive. The time it saved mattered. So did its contribution to making a project of this scope realistic alongside the accumulated work of the existing product.
But “give an agent the Android source and ask for an iOS app” describes too little of the job. Source code records an implementation. A mature application also embodies decisions about navigation, onboarding, teaching, and the relationship between its systems. Some of that understanding lives in code; some lives in content, infrastructure, and the experience of the person who has maintained it.
The founder repeatedly had to decide what the iOS experience should do and whether an implementation served that purpose. He brought engineering judgment, UI and UX experience, product ideas, and teaching methodology to those decisions.
AI accelerated the construction. The understanding of what should be constructed had been accumulating for years.
Faster implementation still took months
Even with those tools and that foundation, the iOS implementation took several months.
There is no contradiction between a large acceleration and a substantial amount of work remaining. A mature product gives a developer more to reuse, but it also gives the new client more to support. The goal was a full iOS version of an established learning experience.
Writing code faster did not settle how a learner should move through the app. Navigation, onboarding, interface choices, user experience, and product logic still required decisions. The founder remained responsible for how those decisions fit together.
Nor did the existing Android interface require every iOS screen to become a pixel-for-pixel copy. The second implementation created room to reconsider the experience, including parts that had become familiar through years of use.
The founder’s experience offers a more useful expectation than the promise of a production app prompted into existence over a weekend. AI can lower the implementation cost enough to make an ambitious project viable. The remaining work still needs time, attention, and a person who understands the product they are shipping.
The port became an audit of Android
Years of maintaining the same application can make its behavior feel normal, including behavior that deserves another look. Building the iOS client gave the founder a fresh view of his own product.
Lesson loading was a concrete example. The older Android implementation loaded lessons from the backend inefficiently. In some circumstances, that could make the application appear to hang or freeze while material loaded.
During the iOS work, the founder revisited how that system operated. The port brought the inefficiency back into view, and the Android implementation was subsequently improved. Several smaller UI refinements followed as well.
That is a benefit a port can produce before counting a single new iOS user: improvements to the first platform. Reimplementing an experience forces decisions back into the open. What had become an accepted part of daily development can become a question again.
The grammar material also received a new presentation during iOS development. The founder sees further room to improve the UX of that section. It is an evolving approach, rather than a claim that one redesign has solved how grammar should be taught on a phone.
Together, those changes show why copying the first client is too narrow a goal. Some established behavior is valuable and should carry across. Other behavior benefits from being examined again. The years behind the product provide a foundation, while a second implementation creates an opportunity to question it.
A first App Store submission needs more explanation
This was the founder’s first App Store submission. He did not already know every part of the process or the App Store Connect interface.
During the initial review, Apple asked for additional material: a video showing the app in operation and a more detailed description of its functionality. He had not initially supplied the screen recording. He then provided the requested material.
The submission eventually received approval after that additional-information step. There was no product rejection or demand for a new direction or major rebuild. The founder needed to supply the requested material and continue through review.
The work at this stage was to make the existing application sufficiently clear to someone reviewing it. Having a functioning app and explaining that app for a store submission were separate tasks.
The Mac, platform tooling, submission information, and demonstration material all belonged to the same launch. They sit outside the narrow act of writing screens, yet an indie developer still has to handle them to get the product into users’ hands.
Waiting was harder than another problem to solve
For months, the founder had been able to act on problems. He could investigate an approach, change an interface, or improve an implementation.
During review, control moved outside his hands. The wait became unexpectedly difficult. As it continued, he wondered whether a rejection was coming, whether something was wrong, or whether the submission had simply disappeared into a queue.
He described the feeling this way:
“At that point, I would have preferred almost any answer, as long as it came sooner. The hardest part was the uncertainty.”
He eventually contacted Apple Developer Support. A few days after that contact, approval arrived.
The approval carried the weight of much more than the submission itself. Behind it were the colleague’s old request, the audience data, the Mac purchase, months of native Swift work, changes to the existing product, and the extra review material.
It was a significant personal milestone because all that work had finally become something an iPhone user could install.
What arrived on iOS
According to the founder, iOS users receive the same broad learning experience already available on Android. The release brings the existing product to another platform, with a path from the Hebrew alphabet and first words through structured lessons, grammar, and reading.
The documented product includes Nikud and pronunciation support, practice, vocabulary review, and beginner texts with translation and audio. The product overview on HebrewEdu shows how those areas fit together.
The founder particularly values the verb functionality beyond absolute beginners. The app’s verb reference and practice cover roots, forms, and binyanim, giving learners something to return to as their questions become more advanced. That is part of the broader product reaching iOS, rather than an alphabet demonstration awaiting the rest of the learning experience.
Learn Hebrew – Read & Speak is available on the Apple App Store, alongside the established Android version on Google Play.
The years behind the new platform
For another indie developer, the encouraging part of this story is that AI made a native iOS client feasible for one person. Existing services and content made the work more manageable, and rebuilding the experience helped improve Android too.
The judgment required to turn implementation into a coherent product still mattered, as did the operational work of entering another ecosystem. Several months of AI-assisted development sat on top of years of backend work, content, teaching methodology, and product iteration.
Much of the original Android product had been built before today’s coding agents were available. Those tools helped carry the accumulated work into a new client. What reached the App Store depended on product understanding refined over years, across many more decisions than a few prompts could contain.
And iPhone users like the colleague who first planted the idea can finally try it.