Our travel manager, Trip Boss, is a comprehensive travel app which posed a unique structure that required an unorthodox solution when bringing it to the iOS mobile market. In order to move Trip Boss to iOS in a way that solves both our customer’s needs and makes it feasible, economically, we came up with a new method of selling—Apps-Within-an-App. The app was originally available on the PalmOS platform, which is much different than the iOS platorm. To ‘port this software to the new AppStore, we had to consider many things: customers needs, data sharing, development time, and pricing. Otherwise, the app would never have come to fruition on the iOS platform. This post will take you through the history, the thought process, the choices, and the final decision and product.
Our travel manager, Trip Boss, is a comprehensive travel app which posed a unique structure that required an unorthodox solution when bringing it to the iOS mobile market. In order to move Trip Boss to iOS in a way that solves both our customer’s needs and makes it feasible, economically, we came up with a new method of selling—Apps-Within-an-App. The app was originally available on the PalmOS platform, which is much different than the iOS platorm. To ‘port this software to the new AppStore, we had to consider many things: customers needs, data sharing, development time, and pricing. Otherwise, the app would never have come to fruition on the iOS platform. This post will take you through the history, the thought process, the choices, and the final decision and product.
Brief Introduction of Creative Algorithms
Let me start by welcoming new readers from #idevblogaday. If you don’t know us already, Creative Algorithms is a husband and wife team, and this is our company blog, Mobile Evolution. My husband, Cory, does all the coding (and IT work) and I do the rest, from UX design and graphics, to marketing, accounting, and other business-related tasks. We’ve been doing mobile software together for 8 years now, and if you want to know a bit more about us, have look on our about page on this blog. Now back to the story…
History of Trip Boss
Trip Boss first debuted in late 2004 and evolved as a travel manager where you can plan your itinerary, track expenses, organize with lists, log mileage, keep a journal, set a budget, plan routes, rate places, convert currencies, calculate tips, and more. All these functions were in one app, at one price, but prices could be much higher on the PalmOS platform. The software was originally based on a spiral-bound travel logbook that our family had kept for all our trips. We expanded on that idea and added features to appeal to business and internationalized it for use worldwide.
When the iOS platform arrived, Trip Boss was a key app to ‘port for us. However, the monumental task of rewriting the app from top to bottom, and the time involved, did not transfer well to the new platform. After the AppStore opened, prices raced to the bottom, and many developer houses decided to target much smaller, simpler, apps with quick development time and greater potential to recover development costs. Large scale projects, similar to Trip Boss, were shelved. Since our goal was to support ourselves on our apps, we took a long look at Trip Boss and then started ‘porting our smaller apps, but creating a base code that we could build on for Trip Boss’ eventual release.
At this point, we knew the only reasonable option would be to break up Trip Boss into pieces, mostly due to development time, but also due to market pricing. However, this situation posed a problem with one of the selling points of the app—it’s an all-in-one type app; each piece works together to tell the story of each trip. As separate apps, the synergy of data sharing would not be possible, since each app is designated to its own sandbox.
In-App Purchase Arrives
One of the benefits of delaying the start of Trip Boss was the evolution of options in the AppStore. When Apple announced the In-App-Purchase (IAP) option, voilà! we had a way to sell separate apps, but combined into one app umbrella. Our customers would also be happy to know they could customize the app by choosing only the pieces they want or need (a big request on the Palm platform). And it was now economically feasible to bring this comprehensive app to the AppStore.
As we moved on to development of Trip Boss, we considered three models, each with different pros and cons. Sell the app as one big app, break up the app into pieces, or piece the parts together into one app through in-app purchase.
Selling the app as one big app was not feasible. Development time meant we would run out of money to support ourselves before it could be finished. Pricing ceilings meant it was nearly impossible to recoup that development cost/time.
Selling as separate apps was possible, but then the essence of Trip Boss as a complete travel manager was lost. Plus, as mentioned, separate apps cannot ‘talk’ to each other, each being in their own sandbox, with separate databases. Global attributes such as places could not be shared. All data for one trip could not be stored together, for future reflection or trip planning.
Selling Apps-Within-an-App does have some cons, however. We had to pick ONE starter app that everyone has to own to get started (did we pick the right one?), the size of the app has the potential to get quite large, and marketing will be tricky. We’ll only have one set of keywords for search and we have to find a balance to convey the idea of a make-you-own app, without making too many promises in the main AppStore write up. Otherwise the reviews could get dicey. In addition, testing time increases, as each time we release a new “app” we have to test all areas, to ensure no new bugs have been introduced. And we are breaking new ground—most in-app purchases are smaller add-ons, or are consumables. Not many sell, through IAP, a fully-fledged app in that manner that could, in its own right, stand alone. Would people be willing to buy apps this way?
Using in-app purchase has many pros. EVERY single customer will receive information on the new “module” (as we’re calling these ‘apps’) when we release the updates to add them. People don’t have to go looking for other travel-related apps we sell—our in-app store is very visible for browsing. Everyone will have a feel for the new modules by using other modules first (almost like a trial). And the apps/modules talk to each other! Common data can be linked, transferred, and shared. No need to reenter information repeatedly or navigate between separate apps. Lastly, the past trip data, for planning, reflecting, etc. can all be found in one place. Expenses can be associated with itineraries, which can be associated with journal entries. Mileage can be sent to expenses and cross-referenced in itinerary planning. The possibilities for synergy seem endless and we’re excited to pursue them!
Final steps
We are on the brink of introducing this new App-Within-An-App approach with an update to Trip Boss. We just submitted our second module, “Itineraries” to Apple today (coincidentally). We had fun with the storefront—a vending machine concept. Modules available for purchase are in the slots (see in the screenshot at the top). When purchased they fall to the bottom. If the module store is closed (no internet connection or IAP disabled) the vending machine appears turned off (see the screenshots below).
You can find a full run-down of Trip Boss, both the released Expenses & Budget starter module, and the upcoming add-on Itineraries module, on the Trip Boss page our website. I also wrote a piece about how we did the design of Trip Boss in an earlier blog post. I’ll keep everyone posted at how the new approach is received, after the update is approved, as time goes on, and as we release additional modules into the system (we have a long list).
