One of the key technology decisions you had to make was integrating multiple iOS Gojek Clone apps with the existing app infrastructure. Notably, the app development approach has always been in favor of native as compared to cross-platform development. Here, different codebases are used to develop Android and iOS apps.
Introduction
Since on-demand apps must be developed for different interfaces, entrepreneurs build them using a single codebase to cut development costs. Here, the driver app, the user app, and the store app are three different interfaces of a single operating system. Therefore, building each app from scratch with a new line of code not only consumes a lot of time but also takes a toll on testing and launch timelines.
To accomplish this feat, you need to replicate the core workflow of the app without taking away the user experience to maintain a consistent flow of change. Hence, the solution requires rebuilding the iOS apps on a newly architected platform that could also support the other iOS apps as well. Although an intensive strategy, it would result in a scalable, on-demand mobile platform capable of supporting additional features in the future.
Building iOS Gojek Clone Apps From The Same Codebase
Given the decision to rebuild and merge the Gojek Clone iOS apps, the first thing to do was build a new architecture underneath the current one. Here, the goal is to share as much code as possible while still being able to build unique features and experiences.
With this in mind, there are three options you could go for:
- separate Xcode targets,
- separate build configurations,
- separate app wrappers around a common app library
Separate Xcode Targets
When you create a new project, Xcode adds one or more targets to the project automatically for an iOS app and a Mac app. Here, a target specifies a product to build, such as an app. Therefore, by building Gojek Clone iOS apps from the same codebase, you can separate targets from different targets to create one simple but unique setup. Moreover, you can repeat the same process with different builds as well.
Here, a simple setup was an attractive aspect of this solution. In addition, the minimal amount of change was also reassuring. However, development speed comes at the expense of maintainability. Having duplicate builds meant that when adding files, developers would need to make the appropriate selections for testing purposes. Segregating files is a pretty straightforward task, but it is also very easy to mess up. Although these issues are easy to fix, they could slow down development, especially when they fail on the CI/CD machine.
Separate Build Configurations
Separating Xcode configuration files requires renaming and debugging the current release, making those configurations specific to the Gojek Clone app. Afterward, those files can be duplicated to create a separate build file for release. This method takes away one app target from the other, and the developer would be able to keep a single build target for both apps. This can mean many things at once.
To begin with, a single target resolves the issue of file target membership. This means the framework of your app won’t be affected by separating configurations. However, expanding the configuration files is a tedious and painstaking process. You would have to define variables for all the differences between the two apps and then map them to their respective dependencies.
Separate App Wrappers Around A Common App Library
This approach involves using the developed app code and framework, extracting them into a static library. Moreover, the desired interface app would then use the extracted data present in the library for all shared application code. In order to do this, take the existing app, strip out all app-specific pieces, and bundle everything together in a static library.
From there on, two new app targets, one for driver iOS and one for user iOS, act as app-specific wrappers around the shared code. This app wrapper includes all the mutually exclusive code and logic from each app. This approach will give you the ability to easily customize each user experience with minimal impact on others.
Overall, the only downside to this solution was the amount of effort required for the initial extraction of the static library and configuring the two new apps for it. However, the maintainability and scalability were well worth the trade-off in additional setup time.
Retaining the iOS look and feel
After developing two Gojek Clone iOS apps, devise a clean and scalable method to style each app. Now, you can either go for complete customization from scratch or opt to buy the complete clone package. Regardless of the case, ensure that the outcome doesn’t impact any set of key user interfaces. Otherwise, it would abstract away the underlying values for each app without changing any code at the call sites.
Conclusion
With the correct method of progress, your iOS Gojek clone app for users and drivers could achieve much more scalability than before. This is because you now have two apps built from a single codebase with distinct themes. Moreover, this shared codebase also means that you can make overall improvements and add features at the same time. It is incredibly helpful for an on-demand delivery company that aims to provide multi-service deliveries and is likely to have new business lines in the future.
