(OT) Runners, don’t trust your Apple Watch Series 2 GPS routes!

We here at Precipice Labs are huge Apple fans.  Not only do we develop software targeted for their mobile platforms but we are former long-time employees.  Despite our love for the Apple universe, we know that sometimes they do drop the ball and we like to help set them straight.  In this case we are talking about the Apple Watch Series 2, at least with respect to it’s use as a training and racing device for serious athletes.  Admittedly, I am not close to the level of a professional athlete and perhaps on the fringe of what one would refer to as a “serious athlete.”   I’m serious in that, when running a race, I have a goal pace and time in mind.  I don’t expect to win or even place in my age group.  I think that about covers 90% of the people entering any given organized public race.  We put in lots of training hours and do our best to hit a goal finishing time.

For years I have been running with a Garmin Forerunner GPS watch.  It’s fine.  It always reported fairly accurate statistics and got the job done.  A few months back, after about 3 years of heavy use, the touchscreen stopped working and I was forced to look into buying a new GPS watch.  Apple had just released the Series 2 of their Apple Watch.  I hate carrying a phone with me on long runs so I was never interested in the prior version of the Apple Watch, which relied on a paired iPhone for GPS data.  Finally Apple added GPS directly to the watch, making it possible to leave the iPhone at home and have the watch track all of the important running data that I rely on.   When training for a race, knowing your pace and distance is vital information.   During the race itself, even more so.  For us non-elite athletes, pacing by feel is not so easy and having this little device tell me how far I’ve gone and how fast I’m running is awesome.

In addition to adding the GPS to the watch, Apple has cobranded it with Nike.  What’s the message there?   Apple is telling us that this watch is meant for serious athletes, not just office workers who want to track how many steps they’ve taken today.  Nike!  The company that makes shoes for Michael Jordan and Serena Williams and Mo Farah!   This watch is meant for professionals!  Surely it will work for me.  I am a serious runner!

So, I bought the Apple Watch.  It definitely has some quirks that I had to get used to, and the running apps that are available leave a lot to be desired.  I settled on the Strava app and used it several times as I was preparing to run in the LA Marathon in March of 2017.  Everything was working fine until the day of the race itself.

Unlike the Garmin watch, which takes minutes to lock onto satellites when you turn on the GPS, the Apple watch starts tracking instantly when you start a run.  At first I thought it was because Apple just lets you start without a good lock on the satellites and accuracy would suffer.   However, looking at my run maps I see that this is not the case.   The starting location for my runs is mapped fairly accurately.  However Apple does it, they seem to have solved the problem that Garmin users still suffer through.  So score one for Apple!  Unfortunately, this is where Apple’s advantage ends.

So, about the LA Marathon…Everything was working fine with the watch at the start of the race.  However, a few miles in I noticed that it is reporting paces that are WAY off what I’m actually running.  Also, I noticed that the mileage reported by the watch was also way off from the official mile markers that were posted for the race.   For example, as I passed the 3 mile marker the watch is telling me that I ran 3.7.   At the 4 mile mark, according to the watch I had run  over 5.   And it got worse from there.   At this point I stopped even checking the watch for anything other than the elapsed time so that I can do the mental math to figure out my pace myself.

As anyone who has used a GPS watch for running knows, the accuracy is never perfect.  It’s even less so during a large race like the LA Marathon.   Runners aren’t always able to take the ideal line through corners and there is a lot of weaving through other runners on the course so we expect a little bit of inaccuracy.  After a 26.2 mile race it isn’t uncommon for a decent GPS watch to report 27 miles or so.  However, the problems with the Apple watch were WAY beyond what I consider acceptable.  But why?  Why did a watch that performed acceptably during training fail so badly when it really mattered to me?  I decided to dig a little deeper to find out.

The first thing to note is that all of my normal training runs took place in mostly open areas where a good GPS signal was available.  The LA Marathon, on the other hand, traverses through areas of downtown Los Angeles where many large building can hinder the GPS  signal required for the device to get a good handle on your location.  This is precisely the situation where the Apple Watch fared so poorly.  With large buildings preventing a good location reading, wouldn’t all GPS watches have the same problem?   Not necessarily.

Let’s take a look at some real data to prove it.   The Strava.com website has an amazing feature called “Flybys.”   This lets you see all of the runners that ran the same route as you did at around the same time.  Additionally, it lets you look at each individual runner to see what specific device they are using to track their run.  Given that Strava is a very popular service and the fact that thousands of other Strava users were running in the LA Marathon, the public has access to literally thousands of data points to see how different GPS devices perform under similar conditions.  Examining this data was quite enlightening.   Admittedly, I did not do a scientific study and only spent a couple of hours looking at this information.   I did not exhaustively study every device used to reach the conclusions that I’m presenting here.  My hope is that Apple will do more thorough research into this and fix their problems.

First, take a look at the route that my Nike Apple Watch Series 2 recorded through a portion of downtown LA with a particularly bad GPS signal (represented by the black line):

AppleWatch

Wow, that is quite the circuitous route!  Note that the true marathon route was actually run on S. Main Street and 1st Street.  The route shown above makes it look like I had done some heavy drinking of something other than Gatorade before the race.  It’s no wonder that my watch was reporting back to me that I had run literally several miles farther than I did so early into the race.

Thinking that perhaps my specific watch has some hardware issues, I hunted through Strava to find another Apple Watch user.   Here we go:

AppleWatchAgain

We can see basically the same kind of jagged path.

Now let’s take a look at a Garmin device (Forerunner 630) :

GarminForerunner220

Yes, we can see the affects of the bad signal here as well but not nearly to the extent of the Apple hardware.  The path of the route is not drawn directly on the road, adding to the reported distance.  However, because the line is kept relatively smooth, the distance added to the run is a mere few percentage points as opposed to the Apple watch which added 20-30%, possibly more, to the actual distance for me.

Here’s another Garmin (Fenix) showing similar results:

Screen Shot 2017-04-06 at 7.37.54 PM

 

My takeaway from this is that the watch knows when it is getting a poor signal.  Or rather, the software that runs on the watch and manages the location services, knows that the signal is poor.  Adjustments can be made by the software to smooth out the route and attenuate the error.  It appears to me that Apple is not correcting for a poor GPS signal and we are left with a watch that is simply worthless under certain conditions.

Despite all of this, I am still a fan of the watch and will use it during training when in a familiar area.  However, I will be using a Garmin device when it matters most during races.  The Nike Apple Watch Series 2 is simply not ready for “prime time.”  Apple still has some work to do.

 

 

The true cost of building a social networking app like Instagram or Snapchat

I’ve recently been looking at job postings on Upwork.com for variations of “we need to build an app like Instagram.”  These appear almost daily and in addition to the base requirement of an Instagram-like app, they also tend to include something along the lines of “Budget = $500-$1500.”

As a developer, unless you have the source code for that app already written from a prior job and are willing to sell it for that price, these budgets would seem impossible to meet.  Or are they?   Before we get to that, let’s break down the job into smaller tasks, look into what kind of expertise is required, and estimate the time to compete each task.  For this discussion we will limit it to iOS just to keep things somewhat simple.

When people without expertise in software development come up with an idea to build “the next Instagram” or “the next Snapchat”, but this time centered around some common interest, they rarely realize exactly what is required.  After all, these apps are fairly simple to use and understand, and there’s not a billion features like there are in other applications that they are familiar with, like a word processing application, so how difficult could they be to develop?

First of all, unlike a word processing application, data is not just managed within the application that you are using. Rather there is need for constant communication with a remote server that will do all of the heavy lifting.  This is that “cloud” thing we’ve all been hearing so much about.   This remote server is responsible for managing data for tens of thousands of users.  Not only storing the photos that have been uploaded but all of the related data like the user comments and ‘likes’.  The server will also deal with managing all of the user information such as login credentials, friendship relationships, and preferences. On top of that, there is the Push notification system, which adds even more complexity since this requires communicating with the Apple servers that actually deliver the notifications to the end user’s mobile device.

At the heart of the server is the database that is used to manage all of this stuff.  The database will need to sort through potentially tens of millions of data records and deliver images and user data quickly and efficiently.  Once this code is designed, implemented and up and running, it doesn’t end there – this data needs to be maintained and backed up!  If a catastrophic event should occur on the server (ever have a personal hard drive go bad?), losing the user’s valuable content is unthinkable and an honorable business should do all that is possible to prevent this from happening.  Another task that might be considered ongoing “maintenance” is simply providing a mechanism for users to report objectionable material so that administrators can deal with it properly.  So yes, this is A LOT that needs to be considered and we haven’t even started talking about the app yet!

Let’s talk about the cost to build the server side.  These are mostly just educated guesses and will vary widely based on the experience level of the person tasked with completing the work as well as the technology choices made along the way.

  1. The server itself.   Some may be surprised to hear this but this part is relatively cheap and in the grand scheme of things almost a negligible cost (at least until we get to very high amounts of data storage).  There is a plethora, profusion, glut, or simply MANY options for cloud hosting services, all competing for this ever-expanding market.  Check out AWS, Microsoft Azure, Linode, etc.
  2. Database design and implementation.  360 hours
  3. Communications layer that allows your app to interact with the database.   400 hours
  4. Notifications system.  20 hours

Basic features involved in the app will be as follows:

  1. Communications layer to deal with sending data back and for with the server. 120 hours
  2. User interface design.  120 hours
  3. Build user interface to display the image stream.  200 hours
  4. Build user interface to capture and edit images.  This one can vary widely depending on what we mean by “edit images.”   For now, lets assume that we will just use the built-in image capturing and editing features provided by iOS so, in that case, there is nothing further to do.  If we’d like to add some simple filters, like those provided by Instagram, we can take advantage of some open source software like GPUImage to save ourselves a lot of work.  Building complex and crazy image effects like you’d see on Snapchat can of course take a lot of additional time and effort to develop.
  5.  User settings and authentication.  80 hours.
  6. User commenting/liking.  120 hours

 

Totals :
Server : 780
App: 640

Grand Total : 1420 hours

Assuming that you could hire good software developers with solid experience in the required technologies (implying that you’re not paying them to spend a week learning what a UIImage is) for between $50-$100 per hour, the rough estimate to build your app would come to between $71,000-$142,000.  Some may say that this is much less than what was originally spent to build Instagram but, suffice it to say, it’s a far cry from the budgets that people are targeting in their Upwork postings.

At the start of this posting I did imply that these unrealistic budgets might not be so unrealistic after all and I meant it!   Enter Ostetso! (cue fanfare).   With Ostetso, ALL of the server-side has be done for you and is maintained by us as part of the service.   As far as the app goes, about 95% of the work has been done for you as well since Ostetso provides you with an SDK that is integrated into your app.  Ostetso handles the image stream, user interaction, user settings and authentication.  The only piece that is left for you to do is to determine what makes your app unique and to customize the look to your liking, handling the image capture and editing (if you choose to do anything with that at all).  Ostetso does the rest.   If you do wish to include image filters in your app, we have already built a complete open source iOS application called SharePictures that provides examples of how to integrate image capture and filtering into an Ostetso-based app.  With Ostetso in the mix, the cost to build a viable Instagram-type app can realistically be brought down into the range of $500-$1500 or potentially even less.

Please contact us for more information.

 

An interview with app developer Todd Bernhard of NoTie Software

We’re starting a new series of blogposts where we take a deeper look at some of the people who are using the Ostetso platform to enhance the social and sharing capabilities of their apps.

Today we’ll be talking with Todd Bernhard of NoTie.com, who has integrated Ostetso into his SkinCam photo app and is now in the process of adding it to some of his other apps.

 

  1. Tell us about your app and your business

My firm, NoTie.com, actually has over 100 apps, but the common thread for most is Text-To-Speech functionality. We have apps like AutoRingtone that let users create custom text-to-speech ringtones for talking Caller ID. Another one of our award-winning apps is AutoVerbal which helps kids with Autism, or anyone who is non-verbal, communicate using talking custom photo buttons.

 

  1. About how many users do you have?

Altogether, our apps have been downloaded over five million times! Most of those are free apps, of course!

 

  1. What category (categories?) do you list your app under?

With so many apps, it varies, but usually Music, Entertainment, Photography, Education, Business or Utilities. We don’t have a lot of game apps.

 

  1. What platforms do you support (iPhone, iPad, Apple Watch, Android, etc.?)

Most of our apps are Universal apps, for iPhone and iPad. We also have three Apple Watch apps, two Apple TV apps, and a couple of Android apps. We even have a couple of Windows Phone apps and macOS apps.

 

  1. Roughly how much time did you spend (man-hours and calendar weeks) developing your app from when you first started on it until it was released in the app store?

Some of my favorite apps were built over a weekend, followed by several months refining them. I’ve participated in a couple of Startup Weekends (and won both of them!) as well as several hackathons and won about a half dozen such contests. I find that a deadline, even if it’s an artificial one like a hackathon, forces me to focus and build a working prototype in a short time. But I always spend the following weeks and months tweaking those projects. The best thing about the App Store is the opportunity to get customer feedback and the ability to turnaround updates and enhancements relatively quickly.

 

  1. What were some of the technical challenges you had to deal with when developing your app?

I am self-taught, since I started developing apps when the App Store was new, so I have to find my own opportunities for learning. Apple has had several Tech Talk Tours which I’ve been able to attend, as well as a few Worldwide Developers Conferences (WWDC.) MacTech also puts on a good conference and it’s cheaper and easier to get a ticket compared to WWDC.

 

  1. What third-party APIs, SDKs or Cloud Platforms do you use in your app? What was it like integrating them? What value did they add?

I use Ostetso for photo sharing, Foursquare for retail info, and a variety of advertising and analytics platforms like Flurry and AdMob. Integration is usually pretty straightforward, but the challenge is finding a partner that has your interests in mind. I used a couple APIs that will go nameless that changed their priorities or were acquired and discontinued service and that is frustrating.

 

  1. How do you market your app? What are some of the challenges you’ve faced with marketing your app?

I’ve tried everything including paid advertising but that seems to just benefit the ad platform. After all, that’s why Google and Facebook are so wealthy. I have found the best bet is App Store Optimization (ASO) combined with free apps of your own that promote and upsell your paid apps which have more features.

 

  1. Can your users interact with each other within your app?

Until recently, my apps didn’t pay attention to letting users interact, but I came across Ostetso and found that it was easy add a social network to my app.

 

  1. If you have a way for users to interact within your app, do you have a way of measuring that activity? What metrics do you collect, and which is most important to you?

I use Flurry analytics to let me know when a user uses my app, takes a photo, customizes it, and shares in with Ostetso. Without such analytics, you are “flying blind” so this is a great way to get inside the head of your customers.

 

  1. Do your users interact with each other OUTSIDE your app via some other method? (Facebook groups, Instagram hashtags, etc.) Please describe.

I give the opportunity for users to share their content on traditional social media networks using the name of my app as a hashtag. Ostetso makes it easy to let users share the way they want and still promote our apps.

 

  1. Do your users actively post photos from your app to other social networks like Instagram/Facebook/snapchat/flickr? (which ones, and do you have a sense for the relative popularity between them for your users?)

Twitter seems to be the best avenue for my users.

 

  1. Do you see any of these external postings driving additional downloads of your app? If so, how do they discover the name of your app?

With Ostetso, rather than just hand off a photo to Facebook, Twitter or iMessage, I can have a custom page that highlights my app and allows users to discover that photo and discuss it and learn about my app. Now, when users share that page, it helps promote my app in a way that Facebook and Twitter can’t.

 

  1. Games are, by far, the most popular category of apps in the App Store (and the one that generates the most revenue). Do you have any plans to do something game-related or do you feel that the space is just too crowded?

Not only is the game category crowded, it’s not my expertise. I tend to develop utility apps that people can use repeatedly, month after month, year after year.

 

  1. What features can we look for in enhancements to your app?

I am very interested in the new features of iOS 10, such as iMessage stickers, so that will probably be the next direction for our apps. I just released PresidentCam which lets users add presidential stickers, like a podium, presidential seal, flags, an eagle, etc., to their photos, with a live augmented reality-style camera view. It’s a lot of fun.

 

  1. How did you get started in the App Business?

I didn’t set out to start an app business with 100+ apps and five million downloads. I just wanted an app that did something that no other apps did at the time, so I went about getting it made. I found that other consumers wanted such an app, and as they provided more feedback, it led me to enhance the app and create more apps to fill the need.

 

  1. What apps are on the home screen of YOUR phone?

Wink for smart home automation, WhatsApp to communicate with my daughter who is studying abroad. When I’m traveling, I make sure Uber, CityMapper, and Hotels.com are on my home screen. Also, whatever app I’m developing at the time, so I have quick access. Right now, those include FlixREMIX and PresidentCamera.

 

  1. Which phone do you use personally?

I think the 4-inch form factor is the perfect size, so I use an iPhone SE. It fits in my pockets, has almost all the features of the iPhone 6s, and has a headphone jack!

 

  1. Anything else you’d like to say about your app?

I try to build apps that add joy, retain value over time, and fill a need. I would close with a request for any user to email the developer of some of their favorite apps. It makes our day to hear from users and if you have a specific feature request, let us know. That’s how apps get better!

How to Create a Photo-Sharing App in Four Hours

(Being a step-by-step guide to creating a fully-functional Instagram-like iOS app
that’s ready to submit to the App Store)

1. INTRODUCTION

This post will be a start-to-finish guide to building an iOS (iPhone/iPad) app that lets users create, modify and share photos to a gallery within the app. By the end of this book you should have an app that’s ready to submit to the app store (assuming you’ve got an account set up with Apple to do that – and we’ll provide some resources to help you with that as well).

Obviously the process of designing and coding a feature-rich photo management app from scratch can be a complicated and intensive process, even if the developer has years of software development experience. So instead, what we’ll be doing is leveraging some open-source code (code that is freely available for download and modification), along with a photo-sharing service called Ostetso (www.ostetso.com – also free to use for smaller projects) to create a fully functioning app in just a few hours.[1] While you’ll need a fundamental understanding of coding in order to create your app, you can polish your skills by modifying the base code and adding in new functionality.

The open-source framework we’ll start with is called Share Pictures and if you want to see what it looks like once it’s been turned into an app you can download the compiled version of it from the App Store directly. It’s a fairly simple app that allows you to apply a few filters to photos taken either from your camera roll or directly from the camera, and if you’re using the camera you’ll even see the filters applied in real-time as you’re getting ready to shoot. Here’s a few screenshots of the Share Pictures app in action so you’ll have an idea of what you’ll be putting together:

Ostetso_screenshot.png

Over the course of this book, we’ll download and configure the Share Pictures code to connect to the Ostetso service, we’ll show you how to modify the Share Pictures code to make it your own, and we’ll walk you through the process of running it on your iPhone or iPad.

Beyond that, we’ll discuss how you can then modify and extend this framework to create an app of your own. Maybe you want to create a variation on Instagram that’s only used by your friends. Maybe you want to have a photo-sharing app that’s exclusively for people exchanging photos of their dogs. We like dogs! Maybe you’ll use this as a starting point to create something that will eventually replace Facebook, Snapchat and Twitter (and make you a billionaire in the meantime). It’s up to you, and once you’ve got the basic app working you’ll be able to explore any direction you find interesting. By starting with the existing template we provide you’ll bypass a huge amount of development (and debugging!) work and get straight to an app that you know is functional, reliable, and ready to release to the App Store. Let’s get started!

2. GETTING STARTED

You’ll need the following things in order to do the development described in this document:

  • An Apple Mac computer. This is the only way to develop software for iOS devices.
  • OS X El Capitan. While not strictly required, your results may not match this guide if you use a different version of OS X.
  • A device running iOS (iPhone, iPad, or iPod Touch). Xcode (Apple’s software development tool, which we’ll download next) includes a simulator for these devices, but unfortunately it doesn’t provide the necessary APIs for interacting with the camera on your laptop, so you’ll be limited in what you can test.

2.1. Downloading Xcode and Signing up as a Developer

Before you can begin working with iOS apps, you need to download the Xcode development environment from Apple. Start by downloading the latest version of Xcode from the App Store. If this is your first time using Xcode, CodeWithChris provides an introduction to Xcode 7 for beginners, and there are a variety of additional resources out there including, of course, Apple’s own documentation here.

If you eventually plan to release your app to the App Store you’ll also need to sign up as a Registered Apple Developer (do so by clicking here), which costs $99/year for an individual membership. But even if you choose not to register just yet, you can still use Xcode to build and test your app locally.

Again we’re not really going to go into great detail about developing apps from scratch in this document. There are already a huge number of resources on the web for doing this. Probably the best place to start if you would like more information on developing iOS apps is the iOS Developer Library.

2.2. Using the Terminal

In addition to working within the Xcode application, there are other things we’ll need to be doing that require using the Terminal app. If you’re not familiar with it, this is a way to more directly interact with your computer’s operating system using simple commands. While you don’t need to be an expert, you should at least be able to use Terminal to navigate the filesystem and run basic Unix commands such as cd, ls, and cat. If you need to brush up on your Unix/Terminal skills, Macworld UK offers a beginner-friendly guide that presents common shortcuts and commands. The Terminal application is available on every Mac, found in the standard Applications/Utilities folder.

3. THE SHARE PICTURES PROJECT

As mentioned, we’re going to be basing our photo-sharing app on the code framework called ‘Share Pictures’. So the first thing we need to do is download that source code. This code is hosted on GitHub, a website where people store code and can track changes to that source code across multiple developers. Not only does GitHub allow you to freely download the code stored there, you can even upload changes to that repository should you enhance or extend the code in a way that might benefit other users.

To download the code for the Share Pictures app, click here, then click the “Download ZIP” button on the right-hand side of the screen.

Uncompress the file by double clicking on it in the Finder and choose a location to place the contents of the folder. This will become our working directory while we modify the source code. We recommend creating a new folder in your Home or project directory called “Development” or “Code” and moving the folder there.

The Share Pictures app is only a part of what we need. Share Pictures uses functionality that can only be provided through separate (third-party) libraries, which we’ll do next.

4. INSTALLING ADDITIONAL LIBRARIES

Rather than download the source for these libraries like we did with the Share Pictures code, we’ll instead install them using a dependency management tool[2] called CocoaPods. CocoaPods isn’t, by default, installed on OSX but it can be added using a simple terminal command. To install CocoaPods, open a Terminal window and enter the following command:

sudo gem install cocoapods

Since we used ‘sudo’ to specify that this command be run as an administrator, Terminal will ask for your password. After entering your password and pressing Enter, CocoaPods will install. When the installation completes, it will show “21 gems installed” followed by a command prompt.

4.1. Installing GPUImage

GPUImage is an open source framework for processing images and videos using a computer’s GPU. Share Pictures uses GPUImage to process images, apply filters, and perform modifications faster than traditional means.

The code for GPUImage is publicly available via GitHub along with installation instructions. The Share Pictures project is already set up to use GPUImage, although we still need to install the framework itself. In the Terminal window, navigate to the directory where you downloaded the Share Pictures project. (If you followed our advice above that would be something like ‘Development’ or ‘Code’. Once you’re there, run the following command:

pod install

This prompts CocoaPods to detect and install any dependencies (Podfiles) found in the current directory (This may take several minutes to complete). While GPUImage is currently the only dependency, Ostetso (which we’ll install next) will eventually be distributed as a CocoaPod as well.

At this point, you have everything you need to build an app capable of taking photos from your phone and applying image-processing effects. But we need to add in one more component that will provide us with the photo-sharing capability we want.

4.2. Downloading and Integrating the Ostetso SDK

Ostetso is a framework for sharing images with all users of an app. Ostetso is a social network for images, letting users share images while providing features common to this sort of community photo gallery. Ostetso makes up the “social” component of the app that we’re creating.

Unlike Share Pictures and GPUImage, Ostetso is not open source (although it is available for free to smaller projects). It’s also not a self-contained tool but rather a framework that makes use of a cloud service (a “Backend as a service” or BAAS) to manage users, store photos, etc.

Because of this, we won’t download the full Ostetso framework into our app like we did GPUImage. Instead, we’ll download only a small portion of code (the Ostetso SDK), which we’ll then use to authenticate our app with the Ostetso cloud service. It’s this cloud service – not the app itself – that does all of the heavy lifting.

You can learn about the functionality provided by the Ostetso SDK by visiting www.ostetso.com/sdk. You can also see Ostetso in action by checking out some of the apps provided by Ostetso’s partners.

For now, we’ll focus on integrating Ostetso into our Share Pictures app. Since the Ostetso SDK isn’t available via Cocoapods, there are a few additional steps we need to take in order to properly integrate it into our project.

First, click here to download the Ostetso SDK. It’s compressed into a ‘zip’ file so you’ll need to uncompress that (the easiest way is to just double-click on the ostetsoSDK.zip file in the Finder) which should leave you with a new directory named OstetsoSDK. Within that directory you’ll find two items: Ostetso.framework and Ostetso.bundle. Move these two items into the Ostetso directory that lives directly under the main directory of the Share Pictures code we downloaded earlier.

Okay, you should now have everything in place to build the app. Let’s do that next.

5. RUNNING THE APP ON YOUR IOS DEVICE OR COMPUTER

Open the SharePictures.xcworkspace[3] file to launch Xcode. You can either double-click the file in Finder, press Command-O in Xcode and select the file in the file picker, or, if you’re still in the Terminal, just type:

open SharePictures.xcworkspace

The Xcode application should open and you’ll see something that looks like this:

You now have two different ways you can see the Share Pictures application in action. If you’ve got an iOS device (iPhone/iPad) and it’s connected to your computer, you can tell Xcode to launch Share Pictures directly on that device.

If you don’t have an iOS device available, you can still see how most things work by using Xcode’s built-in device simulator which will bring up a separate window on your computer that emulates the behavior of a specific iOS device.

For either method, choose the device you’d like to test to by selecting it from the drop-down menu at the top of the Xcode window:

Now, to run your app, press the Run button (the sideways triangle) in the top-left corner of the screen. This will launch the simulator if needed and then in turn launch the Share Pictures app. The main Share Pictures page should look something like this:

Go ahead and click on the ‘Photos’ button. Select an image from the Camera Roll. This opens the image in Share Pictures, where you can edit the image using a variety of effects and filters. Tap on each filter to view its effect, and use the slider on the right-hand side of the screen to change the intensity. You’ll see the effect applied to the image in real-time.

Let’s review what we’ve accomplished so far: we downloaded a base app called Share Pictures; we installed the GPUImage library (which lets us modify images in the app); and we’ve installed the Ostetso framework (which will allow users to showcase their images in a public gallery). And we’ve just tested the app in the simulator or on a device.

At this point you’ve you’ll probably notice that certain things still aren’t working in the app yet – for example the little ‘share’ button at the bottom of the screen that shows up once you’ve applied a filter to an image. And in fact if you try to go to the ‘gallery’ from either the home screen or the upper-right corner of this screen you’ll notice that’s not working either.[4] This is because we haven’t yet configured the Ostetso framework, which we’ll talk about next.

6. CONFIGURING OSTETSO

Before you can see and share to the public gallery of images created by other Share Pictures users, you need to register and configure your app with/for the Ostetso service. This involves three steps: registering as an Ostetso developer, registering your specific app with Ostetso, and supplying your app with a key that it will use to authenticate with the Ostetso service while it’s running.

6.1. Registering as an Ostetso Developer

Create a new Ostetso account via the sign up page. After entering your account details, you will receive an email asking you to confirm your details. Click the link provided in the email, and your account will be activated.

6.1.1. Filling out the Ostetso App Information Form

After logging in to your account, you are taken to the Dashboard. The Dashboard displays a list of apps connected to your Ostetso account. Since your account is new, this list should be empty. To add a new app to your account, click the Add New App button.

Before you can register your app, you will need to provide basic information about the app such as the app name, the App Store URL (if available), the app’s website URL (if available), and contact information for the app’s owner. Not all of this information is required, and most of this information can be changed later. However, this would be a good opportunity to think of a unique name, since we’ll be changing the name from “Share Pictures” to something unique in the next section. – in fact, you can register an app even if you haven’t yet written a single line of code.

You’ll also notice that there’s already an App ID and an App Key shown which was generated during the creation of this new app. You’ll be adding these to the source code of your Share Pictures app shortly.

Once you’ve filled in your app details, press the Save button. You will be redirected to the Dashboard where you can see your new app listed. You’re actually going to be needing the App ID and App Key values In the next section, so go ahead and click on the View/Edit button for your app to return to the App Information page.

6.2. Adding your Ostetso Key to your app

By adding the App ID and App Key values into your app’s source code it will be able to communicate with the Ostetso service every time it runs.

Open Xcode and look for the OstetsoConfig.h file under the second SharePictures directory.

The values that we need to set are OSTETSO_APP_ID and OSTETSO_API_KEY, both of which currently contain placeholder values. Replace the values between the double quotes with your App ID and App Key values. Make sure you preserve the quotes and “@” symbol before the string values. For example,

#define OSTETSO_APP_ID @”PROVIDE YOUR APP ID HERE”

becomes

#define OSTETSO_APP_ID @”E42C6E41-2ACA-E95A-B1C4-C19C9CD0374C”

Rebuild your app and run it in the simulator or on your device.

6.3. Testing with Ostetso

Registering your app with Ostetso means you can now interact with Ostetso’s services such as uploading images and viewing images uploaded by other users. From the Share Pictures app home screen, click on Gallery. You can browse images from specific users and specific apps by tapping the buttons at the top of the screen.

Ostetso_screenshot.png

You can also touch on any image in the two-column view and it will expand to be full-screen where you can see more information about the image, etc.

Note that the app is currently running in a sandboxed environment, so the only images you’ll see are those that have been uploaded by other Ostetso developers. The Sandbox environment is used for developing and testing apps, whereas apps that are ready for release to the App Store run in the Production environment. When an app is in Production, its images will become available to the general public[5].

Click the home icon in the top-left corner of the screen to return to the app’s home screen, then click Photos to browse your Camera Roll. Select a photo which will load it into your app, and then apply a filter (from the list of icons at the bottom) to it. Click on a filter to apply it, then drag the slider on the right-hand side to change the intensity of the filter. Once you’ve applied the effect you like, click the large Share button.

Since you haven’t logged in yet, the app will prompt you to do so. You should use the same credentials you used to register as an Ostetso developer. (You can create a new ID here instead if you wish, but it won’t have the same administrative privileges as your Ostetso developer ID).

Once you’ve logged in, you’ll be able to share your photos to the gallery (you can choose to make them ‘Private’ instead if you don’t wish to do that) and you can also share to a number of external services. The Sharing page should look something like this:

The Ostetso framework provides a variety of additional features related to image sharing as well as a rich set of administrative tools that you, as the owner of the app, can use to curate the user gallery. Please see the Ostetso SDK documentation for more information: https://www.ostetso.com/sdk.

7. ADVANCED OSTETSO FEATURES

Once you have the basic Ostetso functionality working within the Share Pictures app, you might consider extending the base feature set with a couple of additional features that Ostetso provides. Note that these features require you to have an app that’s been registered with Apple and thus they’re something you probably won’t be dealing with until you’ve worked through the next few sections. But we’re putting them here since they’re part of the Ostetso configuration.

7.1. Facebook Integration

Ostetso’s Facebook integration lets you easily share images between your app and Facebook. Images posted to Facebook are branded with your app’s name and link to your app in the App Store. When users click on the image, they’re taken to a dynamically generated web-page that also displays your app’s name and a link to the App Store.

For more information on Facebook integration, see the Facebook Configuration page in the Ostetso SDK.

7.2. Push Notifications

Push notifications let you send notifications to your users even when your app isn’t running. They’re an incredibly powerful way to make sure your users are aware of new content that they might find interesting within the app (if someone has ‘liked’ one of their photos, for instance) and judicious use of Push notifications can pull existing users back into the app rather than allowing them to forget about it.

The Ostetso service can manage these Push notifications for you, saving you additional coding and management time, You will need to configure your app settings on Apple’s developer site before you can make the service available to your users. For more information on how to enable push notifications for Ostetso, see the Push Notification Configuration page in the Ostetso SDK, and then for details on how to tell Apple that your iOS app is Push-enabled, see this Apple Developer resource.

8. MAKING THE APP YOUR OWN

Now you have a working app that successfully manages, modifies, and shares images. You’re almost ready for the App Store, but there are still some steps you need to take before you’re ready to publish. In particular, you’ll need to customize your app so it’s not just a complete clone of the Share Pictures application. First up – pick a new name!

8.1. Renaming Your App

While the name “Share Pictures” isn’t bad, you’ll likely want to change the name to something a bit more personal and unique. The name of your app is one of the first things your users will see, so be sure to choose one that’s both descriptive and memorable. (Also, be aware that Apple will prevent you from registering your app if an app with that exact same name is already in use). If you previously specified a name for your app when you registered with Ostetso then you’ll want to use that same name here.

To change the name of your app, select the root “SharePictures” directory in the project navigator (upper-left corner of the window) and then from the top menu select View > Utilities > Show File Inspector. This will make sure you’re able to see the file inspector in the right-hand side of the window.

Now, In the ‘Identity and Type’ area of the inspector, enter the new project name in the Name field.

For this example we’ll change the name of the app to be “MySharePictures” but feel free to come up with your own name, particularly if you’ve got some idea for what sort of app you’d ultimately like to create. Maybe you’ve decided you want to create an app that’s focused on letting people share close-up photos of of their own smiles. It’s maybe not the most imaginative app out there but getting people to smile is never a bad thing! So in that case you might want to name your app “ShareSmiles” instead. It’s entirely up to you at this point!

Once you’ve changed the name and hit <return>, a window will appear that lets you determine the areas of the app that will change to the new name. By default, everything in the project will change to the new name which is exactly what we want. Click Rename to rename your project.

At this point we’ve updated the name of our project in Xcode, but the app will still display “SharePictures” if you try to build it to your device. To fix this, we also need to change the app’s Display Name.

In the project navigator, open the Supporting Files folder underneath the Share Pictures folder. You’ll see a file called MySharePictures-Info.plist. Double click the file to open the editor, and change the value of “Bundle display name” from “SharePictures” to “MySharePictures. ” Close the file, then re-run the simulator to verify the changes.

8.2. Customizing your App’s icons

You’ve changed the name of your app in the previous section but you’ll probably also want to customize the app’s icon so it is different from the default Share Pictures icon. This is a more involved process than you might expect since in fact you’re going to need to generate a large number of images to satisfy the size/resolution requirements of all the different iOS devices that your app might run on. Many apps, including Share Pictures, also feature a Splash Screen (known as the Launch Image for iOS) that shows up for a few moments when you first launch the app.

This document isn’t intended to be a guide to designing icons – we’ll let you look around the web for some good resources along those lines. You should also go to the source and look through Apple’s iOS Human Interface Guidelines, specifically those related to Icon and Image Design (direct link to that section is here) in order to familiarize yourself with the different required resolutions needed.

The easiest way to generate all the images you’ll need is usually to design one ‘Master’ icon at high resolution and then use that to generate all the smaller icons you’ll need. You can do this manually or (as we recommend) by taking advantage of one of the myriad icon-generating tools that third-party developers provide. There are web-based tools, OSX tools, and iOS apps that all will take in a single high-resolution image (to be safe, start with something that’s at least 2048 pixels square) and with a click of a button spit out all the individual image files your app will require. www.makeappicon.com is one such tool that we’ve used (though they do require you to give them an email address in order to get your icons sent to you), but if you Google “generate iOS icons” you’ll find many others to choose from as well.

When adding images to your app, keep in mind that iOS automatically applies a mask that rounds off the corner of the icons. Apple recommends creating images with sharp 90 degree edges and limited detail around the corners so that the mask doesn’t crop off parts of the image. Incidentally, Apple will also require a larger version of your icon (1024×1024 pixels) for display in the App Store when you go to submit your app.

Once you’ve generated all the icons you need, you’ll use Xcode again to replace the existing Share Pictures icons. Open the Share Pictures app and click on the Images.xcassets resource under the Resources directory. You’ll notice that there are two resources listed: an app icon and a launch images. When you click on either resource, you’ll notice that they contain multiple variations of the same image. These versions correspond to the resolutions that iOS requires.

You’ll also notice that not all of the icon ‘slots’ are filled-in for Share Pictures. At the time this document was written iOS was sometimes, for certain resolutions, able to substitute a similar icon and still support all devices. You might also find, for example, that if you don’t plan to support iPad that you don’t need to generate certain assets for that.

But having said that, it’s usually very little work (particularly if you’re using one of the icon-generating tools as mentioned above) to generate all possible resolutions you might need and put them into your project.

To replace an existing image, simply drag the new image file from Finder onto the image you want to replace. How do you know which images go where? Apple doesn’t make this as clear as you’d think, but the way this works is to look at the specifier for the bin in question which will tell you the ‘Base Size’ of the image and then multiply that number by the ‘Multiplier’ value that’s shown directly below the icon. Here’s a diagram that should make that more clear.

You’ll also need to go through the same process to replace the Launch images for your app with your new artwork.

Once you’ve done all this, rebuild the project and launch it on your connected device (or the simulator) to compile the new images into your app and confirm that you’ve done everything properly.

8.3. Customizing the Gallery

While the Share Pictures app comes with its own default style, the Ostetso framework does allow you to customize the visual elements of that gallery to create a unique look and feel.

All of the visual elements that you can modify are listed in the Ostetso.h file in the Ostetso.framework bundle, under the section labeled “Ostetso User Interface Customization Settings.” This includes button colors, border styles, image icons, fonts, and spacing. In order to change the default value, call the corresponding method in your app at some point after initializing Ostetso with the setApplicationID() method.

For example, if you wanted to change the border color on each image in the gallery to dark red, add the following method to SPAppDelegate.m:

[Ostetso setGalleryBackgroundColor: [UIColor colorWithRed:0.4 green:0 blue:0 alpha:1]];

For more information, refer to the customization section of the Ostetso SDK documentation.

8.4. Applying and Modifying Filters

Thanks to the GPUImage integration, your app is already able to apply a small set of filters to an image but there are dozens of additional filters that GPUImage supports.

We will eventually be adding some more detailed instructions for how to create and modify image filters within the Share Pictures app but for now we’ll give you a few pointers and leave the rest as an exercise for the reader. Also, you might want to read through the GPUImage documentation at GitHub to understand everything that it’s capable of.

For Share Pictures, all of the effects are described/specified within the ‘effects’ folder shown here:

For each effect, you’ll need a few different files but the primary one is the effect description file, which ends with the .fx suffix.

So for example, the ‘Haze’ filter has a description file named Haze.fx. If you look within that file you’ll see that (among other things) there are specifiers for the name of the effect (as it will be shown within the app), the type of effect we’re using from GPUImage (in this case it’s a filter called GPUImageHazefilter), and the icons we’re using to choose the effect when you’re running Share Pictures.

9. PREPARING FOR RELEASE

Once you’ve modified your new app to contain all the features you want and you’re ready to submit it to the App Store, there are a few final steps you’ll need to take in order to tell the Ostetso service that you’re going to be submitting.

Specifically, we need to change the app’s Ostetso environment from ‘testing’ to ‘production’.

9.1. Changing the Ostetso Environment

As mentioned earlier, Ostetso places apps in one of two environments: Sandbox (the default for new apps), and Production.The Sandbox environment is used for developing and testing apps, while the Production environment is only for apps that are ready to send to the App Store. When an app is in Production, its images will be available to all of the app’s users through Ostetso.

Before you can run your app in production, it needs to be approved by Ostetso. Open your app configuration page on the Ostetso website and press the “Submit for promotion to production” button. Ostetso will review your app and will contact you via email once the process is complete. This process can take anywhere from one to five business days.

Once your app is approved, you can switch your app over to Production by changing the USE_PRODUCTION_SERVER variable to YES inside the OstetsoConfig.h file (the same place where you added the APP_ID and APP_KEY values earlier). So it should look like this:

#define USE_PRODUCTION_SERVER YES

10. SUBMITTING YOUR APP TO THE APP STORE

When your app is feature-complete and fully tested, it’s ready to hit the App Store. (And, remember, you need to be a paid Apple Developer before you can do this).

Make sure that your app passes the iTunes Connect validation test and meets the iOS Human Interface Guidelines. Also, make sure you review the App Store Review Guidelines.

Since the base Share Pictures app that’s provided on Github is a copy of the app that has already been approved by Apple, you’re unlikely to run into any problems with this unless you’ve modified things dramatically.

Apps are submitted to the App Store through iTunes Connect. iTunes Connect stores all of the metadata regarding your app such as the app version, build number, name, and category. iTunes Connect also provides tight integration with Xcode, allowing you to quickly and easily upload new builds.

10.1. Creating an iTunes Connect Record

Before you can create a build, you’ll need to create a Record for your app in iTunes Connect. Start by logging in to iTunes Connect using your iOS Developer Program account. Follow the instructions in the Creating an iTunes Connect Record for an App article, making sure to select iOS for your platform. If you want to add additional features such as in-app purchases, GameCenter, or other Apple services, be sure to read the article Configuring Store Technologies. You might also want to use TestFlight to beta test your app before releasing it to the public. We’ll explain how to use TestFlight later in this guide.

10.2. Uploading a Build through Xcode

There are two ways to upload a build to iTunes Connect: Xcode and Application Loader. We’ll upload our app using Xcode, since it’s already tightly integrated with iTunes Connect. Follow the instructions in the Submiting Your App section of the App Distribution Guide. This guides you through the process of configuring your app’s settings, uploading a valid archive to iTunes Connect, and submitting the app for review. The last step is App Review, where Apple reviews and verifies whether your app is ready for the App Store.

10.3. Testing using TestFlight

Testing your app is an opportunity for you to discover and resolve any bugs, shortcomings, or overlooked areas of your app that you wouldn’t have otherwise noticed. It gives you the chance to polish your app, improve the first impressions of your users, and increase sales.

TestFlight is a service that lets you pre-release your app to select users. You can distribute your app to specific users and receive feedback before releasing it to the general public. If you haven’t already, create an iTunes Connect Record and upload a build by following the instructions above.

10.3.1. Adding Testflight Users

TestFlight categorizes users into two groups: internal and external. Internal testers are users who have access to your organization’s content in iTunes Connect and have been assigned the Technical or Admin role. You can invite up to 25 internal testers, and each tester can test on up to 10 devices. External testers are users who aren’t a part of your organization, but who you can still invite to test your app and provide feedback. You can invite up to 2,000 external testers, although your app must conform to the App Store Review Guidelines before it will be distributed to them.

To invite internal testers, open the TestFlight pane in iTunes Connect then click Internal Testing. Click the plus sign (+) to add new testers, then click Add. Adding external testers is a similar process, except you’re required to provide the name and email address of your target users. Note that before you can invite external testers, your build to be approved by Beta App Review.

If testing is limited to users on your team (internal testers), you won’t have to enter any metadata about your app beyond the basic required information. However, if you want to include users outside of your team (external testers), you will need to provide the following additional information:

  • What to test
  • App description
  • Feedback email
  • Marketing URL
  • Support URL
  • Privacy policy URL (optional)
  • Beta App Review contact information
  • Beta App Review notes (optional)

You can add or edit metadata by opening the App Details page, clicking Activity, clicking All Builds, then clicking the build number used for testing.

10.3.2. Enabling Testing

To enable testing, click on the TestFlight pane in iTunes Connect. Select the build that you want to test, then click Start Testing. Your users will receive an invitation via email. When they receive their invitations, they’re prompted to download the TestFlight app onto their iOS device.

The TestFlight app is a centralized location for installing test apps, providing feedback, and notifying users of new builds. Users can test your app for a period of 60 days following the release date.

After reviewing and integrating the feedback provided by your beta testers, your app is ready to submit to App Review and eventually make its way onto the App Store.

11. CONCLUSION

Congratulations, if everything went smoothly you’ve now got your very own photo-sharing app. Now go out into the world and crush Instagram! (Or at least have some fun seeing all the fun imagery your users are sharing and creating).

We’d love to hear about your experience working through the process, about the Ostetso service, and about this guide in general. Was this information provided useful and accurate? If there’s something that we got wrong, or didn’t explain fully, please let us know! You can reach us at bookfeedback@precipicelabs.com.

Or just drop us a note to say ‘hi’, and tell us about the app you’ve created. (Seriously, please do this – we really want to hear about what people are doing!)

[1] And, just in case it wasn’t totally clear, this book was written by the same team that created the Ostetso service and who also wrote the majority of the Share Pictures app before releasing it to the public. We created the Ostetso service because we feel that sharing photos with your friends is a wonderful thing and we want to make it easier for people to do that. We hope this book and the Ostetso framework helps you, as a developer, to create your own awesome photo-sharing apps!

[2] A dependency is code that your software needs to perform a function. Dependency managers let you easily manage multiple dependencies.

[3] If you’ve done any previous development using xCode you probably started by selecting a .xcodeproj file but that changes once you start using CocoaPods, which requires you to use the .xcworkspace file instead.

[4] Also, if you’re running in the simulator the Camera button will work but you’ll only see a white screen instead of the output of a camera. This is normal – to test any sort of camera functionality you’ll need to be running on an actual iOS device.

[5] For more information on the different app environments, see the Changing the Ostetso Environmentsection.

A photo-sharing community within your own app.

screenshot

There’s a particular life-cycle process that most developers go through when they decide they’re going to release a mobile app.  It starts (as it should) with a great idea for a product, followed by weeks/months/years of actually designing and building that product.

And then at some point you start to think about how the app will get noticed, so your worldview starts to include things like announcements and press and marketing (and maybe even advertising).

But even if you’re lucky enough to navigate those waters successfully you may still find that your app isn’t living up to the potential it has.  Because you haven’t developed a passionate community that revolves around it.

We here at Precipice Labs certainly went through all that.  While we put together some fun photo apps like Faceship or FreezePaint and even managed to get some good press here and there, we knew that we needed our users to engage more.  Which meant that not only should they engage with the app itself, they needed to engage with each other.

Sure, they could post to 3rd party social networks like Facebook or Instagram, but that just led them away from the app.  We realized we wanted that level of functionality and community within the app instead.

So we got to work building a framework for photo-sharing – which required things like user accounts, an integrated gallery of photos, push notifications, Likes, shares, comments, etc.  Given that we have multiple apps in the app store, we also quickly realized that it would be even better if people using any of our apps could interact with each other across all of those apps.

From there it was a short walk to our final idea – why not take the framework we’ve built and formalize it so any developer could use it?  Allow event the smallest photo-app developer to have their own integrated photo-sharing network with a minimum of effort… ideally just a few lines of code.  And better yet, if they choose to, they can join into a larger community of apps that are all taking advantage of that same framework.

Which brings us to today.  Precipice Labs is announcing Ostetso, a robust framework that consists of an SDK along with a server back-end that gives all the functionality discussed above.

And for all but the largest apps, it’s totally free.

We’d love to have you check it out.  Take a look at www.ostetso.com for the basics, wander over to the FAQ for a bit more information, and they dive deep at www.ostetso.com/SDK to have all your questions answered, to download the SDK, and to start integrating it into your apps.

And please, feel free to contact us at through our support page (or even on twitter) with any questions or feedback. We want to hear from you!