Kind of tool
Swift — Apple’s own programming language
Where we use it
Why we chose it
Our customer already had a Swift app for iOS. It needed to be fixed, as well as needing to be adapted for other platforms.
Swift is the native programming language for Apple devices, and has direct access to system
Functionality and hardware compatibility.
6 platforms on which the application now runs
250 thousand installations so far
6 months is what it took for us to realize the updated versions
About the project: VPN app
The customer is a Canadian entertainment content platform that is used by people from all over the world. Users in some countries couldn’t access the platform due to blocking. Our client wanted to rectify this problem and open access to content, while also increasing protection for users' personal data. To do this, our client sought the creation of a paid VPN app.
Initially, the customer hired the team that offered the lowest price. They worked on the App Store app for almost a year, but the results weren’t satisfactory. The app was slow: response time was up to 15 seconds. There were a number of repetitive fragments in the code, errors in the code, and the payment system wasn’t working correctly.
The OrbitSoft team needed to:
- Fix the application errors
- Adapt the application for multiple devices and OSs
- Repair the paid subscription mechanism
The task was complicated by the fact that the application had already been published in the App Store: while we were working on the new versions, the old one needed to work and accept payment.
What tasks were solved using Swift
We continued development for iOS using Swift. Using this native language guarantees the speed and quality of the application, and also gives direct access to the capabilities of the device, and the operating system.
Let us tell you what tasks we solved using Swift for this project…
Redesigned the app. In the old version, the interface on different devices was different. For example, if a user had the application on both a smartphone and a tablet, it looked different on each device. Or if a user bought a new iPhone, and downloaded the same VPN app, the navigation was different, and the user would need to search for all the desired functions again. This was inconvenient. Users left, and company’s income dropped. We redesigned everything so that the application now looks the same on all devices, and customers can easily navigate in it.
Fixed custom application logic. In the old version, a user had to create an account before being able to choose a tariff. In other words, they had to first enter personal data, and only then could they find out the cost of the service. People didn’t like this. Instead of registering in this application, they downloaded others apps, and the company was losing many potential customers.
We made the application logic familiar to the client: first, choose a tariff, then register. This required a change on the server side: we added a situation to the program where a person could sign up, and then close the application, without creating an account. Then, at the next login, the application would check whether this unregistered user has paid for the subscription. It makes a request to the server and, if it receives the proper response, displays the account creation screen.
Now the application logic is clear to users. Payment data is always saved, and the company doesn’t lose customers.
We adapted the application for different devices and operating systems. We reworked the application code in Kotlin for Android and Android TV, and in C# for Windows. The Swift code was cleaned of errors, and re-adapted for tablets. The MacOS version was going to be made using Mac Catalyst. This technology brings iPad apps to Mac. But there was a problem…
Apple stores passwords in its secure Keychain storage app, but it’s impossible to access them through Catalyst. As a result, when a user selects a VPN server, the app requires a password instead of connecting. We looked for a solution to the problem in the developer community, and found several pertinent threads on Stack Overflow, but there were no answers there either.
A colleague of ours, who had encountered a similar situation, consulted with Apple technical support, but even they had no answer.
It’s unknown when a solution will appear. We decided not to wait, and reworked the code manually. We expended more resources on the issue, but in the end published the Mac version without error.
Set up a monthly subscription. The old app had bug in the subscription mechanism. For example, on the server-side, data was being read from the wrong fields, and users were incorrectly updated in the database. On the client-side, the logic of subscription expiration polling was broken. The application didn’t know went the paid balance had reached zero. It didn’t remind users of this, and tried to work with a zero balance. People got annoyed that nothing worked. They left. And the company lost money. We fixed the mechanism, and also set up an auto-subscription function. Now the application renews the tariff on its own. The user doesn’t need to enter payment information each time. And the company can now count on that monthly income.
But this didn’t go entirely smoothly. Apple has inconveniently organized the testing of subscriptions: you need to create a separate account, and the tested event can only occur 6 times. To continue testing, we needed another test Apple ID, then another, and another, and so on. We ended up with about fifty. Apple’s official documentation doesn’t mention this, but we figured it out, and successfully tested the application.
- Initial app posted on App Store in August 2020. We released the corrected version only six months later, in January 2021. With all modifications and improvements, the project took about 10 months.
- The application can be installed on 6 different platforms: iOS, macOS, Android, Android TV, Fire OS, and Windows.
- In total, the app has been installed more than 250 thousand times.
OrbitSoft Advice: when Swift can be useful
For which projects it’s better suited:
- Loaded applications using animation, 3D graphics, and/or high-quality multimedia. For example, mobile games.
- Applications that need access to specific functions of the operating system of the device. For example, to the camera, Bluetooth, or Face or Touch ID.
- If you need a more affluent target audience. Sensor Tower estimates that in the first half of 2020, iOS users around the world spent $ 32 billion on apps, while Android users spent around half as much.
For which projects should you choose a different tool:
- Simple, light-loaded applications are faster and cheaper to develop in cross platform languages.
- If you’re interested in a wide audience, you should start by publishing on Google Play. According to Sensor Tower, 53 billion apps were installed on Android OS for the first time in the first half of 2020, and around one third as many on iOS from the App Store.