Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

iOS

My first Swift app is out on the App Store

Hello everyone!

A couple of days ago, I've published my first Swift app on the App Store and I'd like to tell you about it.

TL;DR

I made an app. It allows you to view source code of web pages on the iPhone and the iPad. It was written in Swift. I'd like to share it with you. Promo codes and link at the bottom.

A bit of background

I had the misfortune of contracting pneumonia. Pneumonia symptoms can vary a lot, but mine were thankfully mild. Apart from constant mild fever and some secondary symptoms, I mostly felt fine. However, that didn't excuse me from bed rest. My doctor informed me pneumonia could get really ugly if I tried to walk it off.

As a result, I was extremely bored. Apart from catching up on some reading and some work obligations, I had absolutely nothing to do.

I decided to set a simple, yet serious goal for myself — I was going to make an app and publish it on the App Store. You know what they say about idle hands and devil's work. If you throw in a disease, you've got a mess on your hands and I wanted to avoid that.

What app? (not to be confused with WhatsApp)

Deciding to build an app was fairly simple. Choosing what that app would do was an entirely different matter. I scoured through my development folders, looking at code snippets and simple projects that I've built back in June and July after Swift was announced. I didn't find anything inspirational in there (in terms of ideas), but I did find a failed attempt at making an app extension.

Remembering how frustrated I had been while trying to make that extension, I decided I should probably learn how to make them properly, now that I've had some Swift development experience.

In for a penny, in for a pound. I was going to make an extension. This narrowed it down for me significantly. I have always been interested in browser extensions, and I have written a few for Chrome (mostly for my own use, but if you browse my GitHub profile, you'll find a couple of simple ones I thought people would find useful.

I immediately thought about an extension for viewing the source code of the current page. I often found myself wanting to be able to do that. A quick App Store search showed that one such extension was already out, but I didn't let that discourage me. I was going to make my own extension and decided that I didn't even want to know anything about the one that was already out. I still haven't bought/installed that one.

A weekend project

Extensions are tough. Maybe you won't think so, maybe your experience will be different, but mine wasn't all sunshine and roses. I think my first three hours were spent trying to figure out how to debug app extensions.

Since I was unhappy with the process, I created two Xcode projects. One was the containing app + extension, the other was a completely new app that did everything the extension does, only the information that the browser provides to an extension was hardcoded. That made debugging so much easier. @dinopask

I would test things in the app version and once I was satisfied with how things work, I'd copy (and re-factor) the code into the extension version.

This caused some problems, of course, as the app version could access things like UIApplication.sharedApplication(). The extension couldn't.

Regardless of all the trouble, I figured it would be a nice weekend project. It was — with a caveat.

A note on extension debugging: if you're confused about the process as I was, this is what you do: instead of running the app, select the extension in the fall down menu next to the run button ("the play button"), next to where you pick the simulator/device to run the app on. When you hit run now, you'll be asked to pick the app to run. Pick the app that's going to call the extension. In my case, the app was Safari. Whatever you're making an extension for, you run that. Easy!

The plot thickens

I managed to write the first version fairly quickly after that, even though my stupid debugging process tried to hinder me at every point. I pushed the app out as quickly as I could ant it went through the App Store review like lightning — it only took 3 hours.

I believe Apple speeds up the process for apps using new Apple hardware or new iOS features. Extensions are still fairly new.

When the app was released, Holger Liesegang was nice enough to buy the app immediately and it promptly crashed on him. He sent me a video, allowing me to guess what the issue was, but I already had an update in the review process. This update had a problem of its own, though — it got hit by a bug in Apple's signing process where all apps submitted on Oct 3rd and using embedded frameworks were crashing, and then after that, Apple was outright rejecting them. Even some Treehouse member experienced the issue.

My app (which was perfectly fine apart from a nice assortment of bugs) was rejected twice. Apple fixed the issue the next day and my update was out.

In the meantime I was quickly working on a fix for the first crashing issue. While I was doing that, I realised I was unhappy with how the app worked.

The app would only display the source of the HTML files, meaning it could only display inline styles and scripts. With some HTML parsing magic, I was able to get the URLs for external styles and scripts and I added support for viewing those as well.

Even though the app was native, I had a lot of JavaScript magic going on — the syntax highlighting and all of that was happening in a UIWebView which would go over its memory restriction sometimes and crash. And then it hit me — I developed an iOS 8 app. I could've used WKWebView!

For those unfamiliar with it, WKWebView is a really cool new API introduced in iOS 8 and Yosemite. It has a lot of nice new things like 60fps scrolling, Nitro JavaScript engine (the same one that's used in Safari) and new ways of communication between the app and the web view.

It's faster, meaner and much better suited to what I was trying to accomplish. Using it should get rid of that crashing bug, but that remains to be seen.

Now, my container app was just a bunch of settings for the extension — it didn't do anything on its own. So I decided to change that. I turned the container app into a standalone version of the plugin.

Then I changed the design. And the icon. And I realised I had pretty much rewritten the whole thing, so a couple of days after its first release, I had a 2.0 version.

As I'm writing this, that version is processing for the App Store, meaning it should be out soon. It's a free upgrade for existing users and the app itself is $0.99.

Conclusion

Overall, this was a positive experience for me, even though I had experienced a fair share of frustration. I stuck to some principles I've developed early on in my programming career. The most important one (for me) was not reinventing the wheel. If there was a library out there that did something complex I needed, I'd use it if the license was compatible.

Often it's easy to get caught up in doing things yourself. I'm not saying you shouldn't know how to do things, but you don't need to write everything yourself. It's good enough if you understand how you'd achieve something. In fact, it's kind of hard to find a library that does something you need if you don't know what the problem is. :)

I'll be adding new stuff to Sourcery (that's the app name, by the way), but once I add all the features I have in mind I'll probably switch to support releases (bug fixes and polishing). Unless I get some cool idea, that is.

I think I like Swift more than Objective-C, but I'm glad I'm familiar with both languages because I had to do some Objective-C code as well, while adjusting a 3rd party library for use with my app. Treehouse was a great help for me, after all, it's the place where I learned how to do Objective-C. I learned from books, too, but Treehouse was the foundation for me upon which I've built through tinkering around. Swift I picked up on my own as soon as it was released, but I did go through Treehouse's lessons just to see if I was doing things right.

If you think you have a use for the app and you can afford it, I'd appreciate it. If you don't need it, that's cool, too. If you can't afford it, I've included a bunch of promo codes at the bottom of this post.

I wanted to share this experience because I wondered about many of these things myself when I first got into iOS development. If you have questions about the whole process, or even technical questions, feel free to ask me and I'll do my best to respond.

Thanks for reading!

Dino

Sourcery website featuring a demo video

App Store link

Promo codes

L9766PNRY943
66K4LPEME474
JJLW3F9KF769
WTELLJN6RPRF
A74XHMNKXP3L
FHH39YFKHHXL
JKX9K43JWJ3A
3K74NA3NJEPH
NAL7FR9AW4XY
AXEY3MXF7N9K

Addendum

Sourcery 2.0 is propagating right now through the App Store, I just got an e-mail from Apple saying it was ready for sale. Don't worry if you're still seeing the old version, the update should be out in the next 24 hours. Probably less.

6 Answers

Congrats!

That was a great read, thanks for sharing.

Holger Liesegang
Holger Liesegang
50,595 Points

Congrats, Dino - and thank you for sharing this great insight into the process of building Sourcery with the Treehouse community!

Congrats! A source of inspiration for me.

Roman Randall
Roman Randall
10,069 Points

Awesome man! Just read this, and just bought the app. Awesome to hear Treehouse student success stories.