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.
We developed our first extension in JavaScript (JS), which is great for smaller projects. JavaScript is a lightweight high-level language, ideal for smaller scoped projects like this. These benefits can help minimize developer time and maintain the focus of getting a working extension up and running.
After completing an MVP for the mobile Safari cashback rewards extension, it came time to maintain and expand the feature set. These tasks quickly remind a developer of the difficulties that come with working in a JavaScript codebase:
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:
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?
TypeScript (TS) helps solve this problem. TypeScript is a superset of JavaScript which allows for development with strong static typing not available in vanilla JavaScript. Static typing gives developers the ability to declare data types which make the codebase more robust, meaningful and easier to work in. Providing types to integrated development environments, or IDEs, speeds up development workflows with type information as you work, providing enriched autocomplete.
The major benefit here is that TS catches data type-related errors that would be runtime errors in JavaScript at transpile time. An IDE can accelerate this further and help a developer catch the type error as they write instead of waiting until transpile time. TS prevents a developer from building an application with type errors, minimizing the possibility of runtime errors.
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.
For example, if a developer attempts to call a function, unaware that the function is dependent on passing in an array, and fails to pass an array in the call, JavaScript would not throw an error until runtime. But by providing types to function parameters and return values, TypeScript will throw an error at transpile time and not let you complete the transpilation.
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.
In order to continue to effectively scale and avoid possible runtime errors, we migrated our iOS Safari cashback extension codebase from JavaScript to TypeScript. Migration requires time, but the benefits from working in TypeScript help pay this investment back quickly and produce a more robust codebase.
JavaScript got us to our MVP. Now Typescript will enable us to efficiently extend our iOS cashback extension capabilities while delivering top-notch products to multiple partners.
Are you a software engineer interested in working on iOS extensions, solving challenging development problems , and creating coding efficiencies?