Menu

Colin Devroe

Reverse Engineer. Blogger.

I am happy that I have to do very little to my app’s UI for it to work on the iPhone X. Apple has handled that well.

E19: Launching Summit’s public beta

Recorded on August 23 2017.

A quickly captured audio bit while walking to get a coffee the day after launching Summit’s public beta.

Download MP3.

An auto layout constraint bug is hindering progress on Summit. I hope to get over this hurdle soon so that I can resume improvements to the app.

Pedometer++ 3.0

_DavidSmith:

I’ve been steadily working on Pedometer++ now for nearly four years. Over that time the core conceit of the app has remained the same, to motivate you to be more active. It has done this with colors, confetti, complications and streaks. Now I’ve added another tool to hopefully motivate, achievements!

Pedometer++ continues to be my favorite step counter*. I’m looking forward to trying out this latest release.

* Yes, I’m building Summit, but that doesn’t mean I won’t still use Pedometer++ and Map My Walk. Each of these apps play a different role. I hope to make Summit good enough to fill a role for others too. But not the same role as Pedometer++. Even though the number one feature request is that I add more stats – that isn’t what Summit is about.

Colin Walker on the Summit beta

Colin Walker:

I’ve thoroughly enjoyed the time I’ve spent beta testing Summit and look forward to the new builds.

Colin has provided excellent feedback on Summit. So have so many of the beta testers. I too am looking forward to publishing new builds.

If you’re on the beta list (which you can get on by putting your email address in the form on this page) and you haven’t gotten Build 15 yet – please let me know. Build 16 is due mid-September.

Just issued several invites to the latest build of Summit via Test Flight. I’ve already doubled the number of beta testers. Looking forward to the feedback streaming in.

Presenting at the August 2017 Lehigh Valley Tech Meetup

The Lehigh Valley Tech Meetup is an excellent community in the Lehigh Valley that meets monthly at the Ben Franklin Technology Partners incubator within the Lehigh University Mountaintop campus. The community around the meetup is excellent and the building is amazing*.

While the tail-end of my presentation walked through my experience building my first iOS app Summit, the majority of my presentation was focused on helping early stage companies think about their go to market strategies.

I’m currently advising several companies, a few of which are businesses built around mobile apps, and have heard about 11 other start-up pitches this year so far. And during that time I’ve noticed a trend. Entrepreneurs that are attempting to build a business around an app sometimes underestimate the amount of thought that should go into the marketing and sales strategy for the app. It is as if some feel that apps are less thought and work than products that you can touch. So during my presentation at LVTech I hoped to convey that the same “boring” (yet, tried and true) business practices that apply to products also apply to software.

A few questions I urged those thinking about building a business around an app were:

  • Does your idea service a large enough segment of the market? We hear the “scratch your own itch” mantra a lot. However, it won’t always lead to finding hundreds, thousands, or tens of thousands of customers.
  • How will you reach those customers?
  • Are there ways to expand your idea into other products or services that can be sold to the same segment?
  • How will you sell or package your idea?
  • What will the price be? (free, one-time payment, subscription, service contracts)
  • What channels can you leverage to sell your idea? (App Store, retail, online, conferences, distributorships, via a sales force)

By considering these, and may other questions, you can determine if your idea has enough layers to support an entire business or if you just have an app idea**.

I also briefly discussed three misconceptions I’ve been seeing over the last year dealing with very early stage start-ups. These misconceptions were:

  • Press-based launch strategies: some thing that by being covered by press will be enough to get them to profitability. They have no other strategy. On the contrary, getting press coverage early on will give you very muddy analytics which will make decision marking very difficult. Very seldom are the tech audience your real customers.
  • How long until profitablilty: More and more entrepreneurs begin with the plan of losing money for 3 or more years. I believe this stems from press coverage of other companies getting large rounds of funding. Most businesses should strive for profitability within the first quarter or year of business.
  • ”I’m not technical, I need a technical co-founder”: Don’t be this person. Anyone can learn to code. Geeks are not smarter than you. They’re just interested and relentless. Be the same.

We then did about 10 minutes or so of questions and answers. The questions I got were really great and I appreciate all those in attendance helping me with the answers to the questions I didn’t have much experience in.

Thanks to Tim Lytle for the invitation to speak and to Ben Franklin Technology Partners for the continued support.

* I worked in this same building for years while at Viddler. But when I worked there the back half of the building didn’t exist. In fact, Viddler started in Jordan Hall – the building just beside the new building. And now, they are extending it even further. The building is an amazing place to work and have a meetup of this kind. I’m jealous that our incubator in Scranton feels so dated when compared to this building. Especially comparing the meeting spaces.

** It it totally fine to “just have an app idea”. I do. And I’m loving working on it. But it is also good to have the proper perspective about your app idea.

Repost: Dan Kimbrough on Twitter

Dan Kimbrough:

Cool new step counter, created here in #nepa. http://cdevroe.com/summit

Summit – The Adventurous Step Counter

This evening, at a presentation at the Lehigh Valley Tech Meetup, I’m opening up public beta access to my new iOS app, Summit – The Adventurous Step Counter.

I’ve stitched together a temporary web site for the app as well as a mailing list that will allow you to get access to the final few beta builds prior to public release. If you have an iPhone please consider signing up and giving it a spin. I’d be very grateful for your feedback.

Thanks to the 13 private beta testers who have already tested the app and provided feedback. You can expect a brand-new build of the app coming in September.

What is Summit?

Summit is a free, iOS-only app that uses your step count to virtually hike up tall peaks like Mount Everest in Nepal, learn about amazing landmarks like Diamond Head in Oahu, and even take a leisurely stroll down famous streets like Lombard Street in San Francisco. As you make progress on your journey you’re provided new information at each goal.

At the time of public release there will be 5 summits and new summits will be added each month thereafter.

Here are some screenshots of the app as it is currently:

When I started on Summit I did not know how to develop an iOS app. It has been really fun to learn Swift, Xcode, iTunes Connect and Test Flight, and the myriad other things I was able to learn in order to get this app as far as I have.

I still have a bit of work to do, but I’d love your feedback along the way as I finish the app up for release.

An announcement post will be published on my blog in just under 4 hours. May your brow drip with the sweat of anticipation until then.

I can work on anything I want

One of the most enjoyable aspects of working on your own project is that there is so much to do. That may seem strange, why would I want to have so much to do? But if you look at it a different way it becomes a much more enjoyable experience.

Whenever I sit down to work on my pet project, a new iOS app, I can choose what I’m in the mood to work on. Perhaps I’m in the mood to work on the branding, editorial, licensing, or marketing? Or, would I prefer to hunker down into some Swift programming and refine the datastore, algorithms, animations, speed, etc of the app? Or perhaps I’d like to identify key strategic partners for my product launch or look through beta user feedback or do some artwork?

You see the point? Yes, there is a lot to do. And it can seem overwhelming if you allow it to be. But, no matter what type of mood I’m in I can make some progress on the project nearly every single day. And I’m having a ball so far.

I try to think of everything that I do as practice.

I rewrote some of my app’s UI last night using Swift rather than Storyboards. While it takes me longer (at least currently) to build Views this way – it does seem to be the better way of going about it.

Published Build 11 of my iOS app to TestFlight this morning. Some great improvements in this build. Now to fly the UAV a little.

Observations on building my first iOS app in Swift

In early June I decided I wanted to learn iOS app development using Swift.

I’ve made a lot of progress over the last month, building two apps that I can use on my own phone, and one app that I’m now in beta testing via TestFlight with a few friends. Over the last month I’ve made some observations on the process of building an iOS app, the Swift programming language, Xcode, iOS frameworks, and the various other bits needed to make an app. I thought I’d take the time to jot those down.

These are in no particular order:

  • Swift is growing on me rather quickly. The idea behind Swift has always interested me, but I hadn’t really given it a try until now. Like any new language you need to work with it for a time before some of the things that you may not like about it, you end up seeing the wisdom in.
  • I’m very glad I waited until Swift 3 before trying it in earnest. The tutorials I’ve come across for earlier versions make it clear the language has matured in a short period of time.
  • Using Storyboards in Xcode is not intuitive whatsoever. I know many people avoid them altogether (from what I’ve seen on YouTube). Unless you watch someone build a Storyboard you’d likely never, ever just figure it out.
  • iOS frameworks are bulky. It is no wonder so many apps are so big. Just including one or two frameworks for my very simple first app ballooned the app to over 15Mb.
  • That being said, iOS frameworks are very useful. With just a few lines of code you can get something working quickly.
  • Playgrounds are very useful to learn Swift.
  • The Playgrounds compiler can become stuck rather easily. Especially if you paste in a bunch of code from your project to mess around with and get it to work. I’ve had to restart Xcode several times.
  • Xcode has crashed on me a few times over the last month. Crashes on macOS (and also most Apple apps) are very rare. So to be working on something so fragile seems out-of-character. Especially with how simple my apps are currently.
  • Auto Layout baffles me still. I have a working UI for one of my apps that works across multiple device screen sizes. But it is far from what I’d want to ship with. I’ve watched a lot of videos on how to use Auto Layout but I still can’t make heads or tails of it. I’m waiting for the moment it clicks.
  • The connection between labels and buttons and other UI elements in your Storyboard and your Controller class is far too fragile. You should be able to rename things, delete things, move them around without completely blowing everything up and starting over. Example: If I CNTRL+Drag a label onto my Controller and create an Reference Outlet for it… I should be able to rename that Outlet without needing to CNTRL+Drag again. I don’t know how, but somehow.
  • Did I mention that Auto Layout baffles me still?
  • Building and deploying an app to iTunes Connect in order to add to the App Store or Test Flight is an entirely un-Apple-like experience. There is no Step 1, Step 2, Step 3 type of workflow. Similar to Storyboards it is not something you can figure out – you must watch or read to learn. It feels like it was never designed by a Product person.
  • Building an app that resides on a device like the iPhone is an amazing experience. While I’ve always been able to load my web apps on a phone, and I’ve built some apps that use a WebView to deploy across multiple platforms, this is the first time I feel like I’m touching my app when I use it. There is nothing that comes close to native UI.
  • Also, building an app that requires no connection to the web has been really fun. It is so fast! I’d like to move forward by trying my best to keep HTTP request at zero or as low as possible.
  • The amount of information an iOS device knows at any given time is pretty amazing. It can know (with the user’s permission) where it is, what altitude it is at, which way it is pointing, how many times the person’s heartbeat that day, what it is looking at, etc. etc. Amazing to play with these features.
  • The Xcode IDE is really incredible to use. You may not remember a framework’s properties but you can just begin typing a reasonable word and expect that Xcode will figure out what you’re trying to accomplish. Also, if you happen to write older syntax because you’re following an out-of-date tutorial, it will automatically convert it to the most recent syntax.

Overall I’ve had a positive experience learning to build an iOS app on my own. Going from having an app in TestFlight to shipping an app feels like preparing to cross a desert on foot. But, I’m enjoying my experience so I’m going to trudge forward to do so.

I hope to ask for public beta testers of the app in a few weeks or a month.

You never get to “start over”. You only get to try again. There is a big difference.

Peter De Vries wrote “Write drunk. Edit sober.” I feel the same about most ideas. Speed through version 1 as fast as you possibly can getting all of your ideas onto the “canvas”. Then slow down, remove anything unneeded, and refine version 2. Version 2 should be what you ship.

Programming isn’t very difficult. However, frameworks, dependencies, device hardware and software fragmentation, and distribution are all very difficult.