With the release of iOS 15, Apple took a leap forward, carving a path for mobile browser extensions by introducing iOS Safari app extensions. These extensions enhance users’ browsing experience by extending the native app capabilities of Safari.
When this feature was announced, we leveraged its capabilities and built the first white-label mobile Safari browser extension for cashback rewards. Our partner Acorns was the first Wildfire client to take advantage of this enhancement to customer experience, launching the Acorns Earn mobile Safari browser extension to create additional earning opportunities for their customers using iOS.
During development of our first iOS Safari app extension there was minimal documentation available, which made producing an MVP (minimum viable product) time-consuming and challenging.
Developing for mobile also introduces additional constraints developers must consider such as user battery life, processing power, storage, etc.
When researching and developing the first product in newly-available technology, there can be a lot of distractions and a tendency to overthink solutions, which makes it imperative to avoid unnecessary layers of abstraction.
Another factor that must be considered while working on iOS Safari cashback rewards extensions is the development lifecycle, including testing. The process can be very tedious relative to working on desktop cashback extensions.
Here’s a look at updating code in an iOS Safari extension and testing the update:
- Make the change in an editor and check your work to avoid errors.
- Create a build in Xcode.
- Run your build on a simulator.
- At this point, you're almost done. But wait - this step then opens the iOS application as if it were a fresh install. This makes sense, but is tedious when you are working on an extension on the web and have to keep navigating back to the browser where the extension is executed.
- Depending on the complexity of the extension, there could be multiple steps in the browser to successfully test an update, and of course there’s the possibility of incurring a runtime error.
Runtime errors are errors encountered only during the execution of the code. These errors can be time-consuming because they are not caught until after going through this entire process mentioned above: transpiling, building, and navigating through the browser UI.
The worst scenario is if the error occurs due to an edge case or even just any case not tested. Then you might not catch the error and instead your users could experience this unexpected behavior. But what if you could catch these errors in the code as you type or, at the latest, at transpile time?
Accelerating the Development Process with TypeScript
Finally, TypeScript is also increasingly helpful as you scale your application and team. The more code, the more likely the chance of errors. In large codebases, it can be difficult to track down what functions do and require.
But with TypeScript, developers no longer need to track down what parameters and return types functions require, as they are clearly defined by the function signature. With TS in IDEs these values are available wherever a developer wants to call a function. This is especially helpful for developers with minimal knowledge of the codebase.
TypeScript Creates Maximum Efficiency for Wildfire
Are you a software engineer interested in working on iOS extensions, solving challenging development problems , and creating coding efficiencies?