My journey creating a no-code native mobile app

Here at pennantchase.com, we offer the full functionality of the website on both a traditional browser as well as in the mobile app. The mobile app serves mostly as a marketing channel: in years past, nearly 50% of our leads came from the App Store. That percentage has dropped over time as more apps have flooded the App Store, but it remains a strong source of new users. In addition, some users prefer the app over the website for a variety of reasons that I won’t dive into here.

Overall, it’s been beneficial to have an app, but as a solo web developer, it’s been a significant pain to maintain. The beauty of writing for the web is that code works for a long time. I’ve got code that’s over 20 years old and still runs beautifully in all major browsers. But native app development requires upgrades as the hardware and publishing requirements change.

Every three to five years, the app needs a rebuild. The website has been around for 13 years as of the writing of this article, and I’ve created five different versions of the app. The first version (2010) I built myself in Objective C, back when I had more time and energy on my hands.

The second version (2012), I wanted to avoid Xcode, and I wanted to be able to launch on Android simultaneously, so I used a program called Corona Labs. This was essentially a “low-code” solution that leveraged LunaScript. It was a great solution, cutting my development time significantly while producing a cross-platform version.

The third version (2015) I outsourced to a contractor. This was before the rise of UpWork and other gig sites, so I had to find this person myself. He used Phone Gap and did a great job, but it cost me somewhere around $5,000. Then he got a full time job and couldn’t help with updates.

The fourth version (2018) I outsourced to an UpWork contractor. He also did a great job, and he was able to leverage the old Phone Gap code, so the cost was a little less ($3,000). But within a couple years, that version stopped working on Android devices for whatever reason, and became pretty sluggish on iOS.

The fifth version I launched this year (2022) myself using Thunkable’s no-code solution. This is the journey I’m going to expand on in this blog post.

First, let me discuss the requirements of the Pennant Chase app. The features are pretty simple. The app needs to accept login credentials, store those securely, and log the user in. Once logged in, the user has access to a native navigation control, which triggers WebViews into the pennantchase.com website. (There is also an option to Sign Up through the app.) Another critical requirement for me is to make the App Store submission as painless as possible. I no longer own a modern Mac, and I recall App Store submission being a grueling process.

I was prepared to dive back into UpWork and find a contractor, but then I saw an article about Thunkable raising an additional $30 million, and I thought, “Why not see if I can do this myself with little effort?” After all, no-code has made great strides, right?

Well, sort of.

This fairy tale does end happily, but not without a fair amount of pain inbetween. I first set out to figure out which platform would best suit my needs. I started with Thunkable, but I became a little overwhelmed by the UI of the application. I figured Reddit must have some advice, so I poked around and discovered Adalo. This tool has an amazingly intuitive UI, but there were a couple problems. 1) The Reddit community warned me that Adalo did not produce production-ready performance. 2) The features were befuddling. I couldn’t figure out how to simply log a variable into app storage. The only option seemed to be using an external database, which I did not want or need.

I then dug into Flutter, AppGyver and Bubble.

For my needs, Thunkable was more appealing than all of them. The cost of Thunkable was lower than some, and Thunkable had very clear instructions on how features worked and how to ultimately submit to the App Store. I played around with each tool for a bit, but it became clear Thunkable would be the easiest of the tools while providing all the specific features I needed.

Thunkable is less drag-and-drop and more about snapping together logic tiles. As a developer, this was extremely intuitive, but someone without a coding background might find this challenging. It took me 20 minutes to get comfortable with the layout of the platform, but once I understood how it worked, I found it quite easy to use.

Once I dove into Thunable, though, nothing went as smooth as I hoped.

The first big issue came after spending a couple hours building my app. Thunkable has two design platforms: Snap-in-Place and Drag-and-Drop. SiP is the legacy platform, and DnD is the newer platform. (I was building my app in DnD.) Unfortunately, the new DnD platform has major issues, most notably the WebViews were not filling the entire screen. It became clear from the forums that there was no easy way to ensure the WebViews would fill the screen for all users. This was a show stopper.

I had to rebuild my entire app on the Snap-in-Place platform (which Thunkable says they are eventually retiring, and that is a major concern). The Snap-in-Place platform worked beautifully, so I decided to forge ahead with Thunkable, even though I was highly concerned they were going to discontinue this platform. Hey, if I could get five years out of this app, it would still be worth it.

That wasn’t the end of my struggles. The bottom tab navigation control leaves a gap at the bottom of the screen, which looks horrible. So I had to make a compromise and use a top tab navigation control (something that is highly unusual - mobile users are accustomed to the tabs being on the bottom of the screen).

I also wanted to place a background image on the panel at the top of the screen, but that failed to work. Also, I needed to encode my WebView URLs, but that was not an option. This was almost a deal breaker, but I worked around the limitation in a super hacky way by doing a string-replace on all the special characters. Maybe most shocking of all, Thunkable does not support a custom splash image. Really!?!

After far more time, energy and frustration than I would have expected from a no-code experience, I had a workable app that was polished enough for production. The testing experience through Thunkable’s app is hit and miss - many times it would take hours for my changes to appear in the app.

But, once I got to the App Store distribution phase, Thunkable really shined. They have excellent documentation and my publishes to the App Store were flawless. The process of publishing to Apple’s store is a lot of work no matter what you do, but Thunkable made it easier than it would have been if I had been on my own.

No-code and Thunkable also really shined when I needed to clone my app for the Basketball version of the site. It was incredibly easy to change a few URLs, change a few colors, and have a second app ready to publish. Once you understand how the platform works and what its limitations are, you can really accelerate your development.

Overall, the initial experience took a lot more time than I was expecting or wanted to spend on this effort. But the end result was a success. I had two apps live for a cost of $45, which likely saved me anywhere from $3,000-$10,000. (I’ve actually spent $90 because I have not yet paused my Thunkable subscription.)

My users love the app - they say it’s functioning vastly better than the previous version.

No-code native app development has a long way to go. The entire process was far too cumbersome and required too many compromises. But if your requirements are minimal, it can definitely save a little time and a lot of money.

I expect when I need to rebuild the app again, the landscape will have changed vastly. (But hopefully for the better.) For now, I’m extremely happy with what Thunkable provided. I truly hope in five years no-code platforms will have moved forward and not backward.