Panel

Aaron Douglas (twitter blog)
Ben Scheirman (twitter github blog NSSreencast)
Andrew Madsen (twitter github blog)
Rod Schmidt (twitter github infiniteNIL)
Jaim Zuber (twitter Sharp Five Software)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:11 - Scalable Cloud Apps and iOS Programming
 02:51 - iCloud Core Data
 04:44 - Scalable Cloud Services

Synchronization
Amazon S3
Amazon EC2
Parse
Syncing
Authentication
Simperium

09:31 - Use Cases

Migraine Diary

12:00 - SDK and Basic Operations

PFObject
Querying
PFQuery

18:11 - Platforms Supported by Parse

Android
Windows Phone
MacOS
.NET
Unity UI

18:41 - Pros and Cons
 25:59 - “Selling” Parse Use to Companies
 27:20 - Choosing Parse

Windows Azure

32:03 - Realtime Interaction

Cheddar

34:17 - Other Services

Simperium
Firebase
Helios
Dropbox

38:32 - Advice for Others

Appside/Server-side
TICoreDataSync
Understand Scaling

41:41 - Rolling your own vs using Parse

Data Privacy

Picks

Mac Dev Weekly (Andrew)
Gwynne Raskind: Friday Q&A 2012-03-02: Key-Value Observing Done Right: Take 2 (Andrew)
11 Untranslatable Words From Other Cultures (Andrew)
Linode (Ben)
Digital Ocean (Ben)
Big Nerd Ranch talk on API design (Ben)
FlatUIKit (Rod)
iOS7Colors (Rod)
Sylvan Dale Guest Ranch (Rod)
Bloons Tower Defense (Chuck)
Fieldrunners 2 (Chuck)
Base 2 (Aaron)
Spark Inspector (Aaron)
Simplenote (Aaron)
TICoreDataSync (Aaron)

Next Week
 Networking with Cocoa with Steve Madsen
 Transcript
 CHUCK: So if I call you Andrew, or if I call Andrew, Aaron, sorry guys…

AARON: [Laughs]

BEN: Just run with it.

CHUCK: Hey everybody and welcome to Episode 21 of The iPhreaks Show! This week on our panel, we have Ben Scheirman.

BEN: Happy Apple Christmas Day! And hello!

CHUCK: Apple Christmas Day…

BEN: Yeah! Today is the launch date. We’re going to find out all about in like an hour.

CHUCK: Oh, that’s right!

BEN: This would be all over the news by the time this sure comes out…

ANDREW: It’s the only thing all of us were thinking about.

BEN: [Inaudible]

CHUCK: [Laughs]

ANDREW: I can’t breathe.

BEN: That’s right. We’re already on the clock, Chuck.

CHUCK: Okay.

BEN: [Laughs]

CHUCK: We also have Andrew Madsen.

ANDREW: Hi from Salt Lake City!

CHUCK: Rod Schmidt.

ROD: Hello from Salt Lake City as well!

CHUCK: Jaim Zuber.

JAIM: Hello! I just returned from the north shore of Lake Superior, where I was teaching berries to code iOS.

CHUCK: I’m Charles Max Wood from DevChat.tv. We have a special guest, and that’s Aaron Douglas.

AARON: Hey! How’s it going? I’m saying hi from Milwaukee, Wisconsin.

CHUCK: Pete would be so proud of me, I didn’t butch your name.

AARON: [Laughs]

CHUCK: We have you on this week to talk about “Scalable Cloud Apps”.

AARON: Yeah, definitely.

CHUCK: I asked you before the show, I’m going to ask you again, how does that relate to iOS programming?

AARON: I’ve noticed that a lot of us iOS devs come from more of the finite programming that we know – JavaScript and CSS – it’s just this kind of a logical step into iOS app development. I came from a Java enterprise background so I’m very familiar with writing apps that are behind other apps. I noticed that a lot of iOS developers are afraid of integrating their app with a server, and that there’s a lot of apps that have to talk to other users or there’s central data. So I think it’s a really important topic just because apps can be so much more powerful if they are connected with other people.

CHUCK: Absolutely. Are you talking about API services like Facebook or Twitter? Or, are you talking about more of the backend systems like Parse?

AARON: Yeah, it’s more of the backend systems like Parse.

 

So if I call you Andrew, or if I call Andrew, Aaron, sorry guys…

Just run with it. [Intro Music]

Hey everybody and welcome to Episode 21 of The iPhreaks Show! This week on our panel, we have Ben Scheirman.

Happy Apple Christmas Day! And hello!

Apple Christmas Day…

Yeah! Today is the launch date. We’re going to find out all about in like an hour.

Oh, that’s right!

This would be all over the news by the time this sure comes out…

It’s the only thing all of us were thinking about.

I can’t breathe.

That’s right. We’re already on the clock, Chuck.

Okay.

We also have Andrew Madsen.

Hi from Salt Lake City!

Rod Schmidt.

Hello from Salt Lake City as well!

Jaim Zuber.

Hello! I just returned from the north shore of Lake Superior, where I was teaching berries to code iOS.

I’m Charles Max Wood from DevChat.tv. We have a special guest, and that’s Aaron Douglas.

Hey! How’s it going? I’m saying hi from Milwaukee, Wisconsin.

Pete would be so proud of me, I didn’t butch your name.

We have you on this week to talk about “Scalable Cloud Apps”.

Yeah, definitely.

I asked you before the show, I’m going to ask you again, how does that relate to iOS programming?

I’ve noticed that a lot of us iOS devs come from more of the finite programming that we know – JavaScript and CSS – it’s just this kind of a logical step into iOS app development. I came from a Java enterprise background so I’m very familiar with writing apps that are behind other apps. I noticed that a lot of iOS developers are afraid of integrating their app with a server, and that there’s a lot of apps that have to talk to other users or there’s central data. So I think it’s a really important topic just because apps can be so much more powerful if they are connected with other people.

Absolutely. Are you talking about API services like Facebook or Twitter? Or, are you talking about more of the backend systems like Parse?

Yeah, it’s more of the backend systems like Parse. There’s a lot of data that the primary use case that I see is that you have an iPhone app and you wanted that data to sync to the same users of iPad without them having to worry about it. It should be iCloud, but we know it’s not. [Laughter]

Maybe that would be the announcement today; iCloud is much better now.

We promise.

That’s right. We gave it some epic hack. No, I’m just kidding. [Laughter]

It couldn’t hurt, right?

I don’t know if we really talked at length about the trials and tribulations of iCloud Core Data. From my understanding, I haven’t done it at all, but from my understanding, the plist serialization or whatever, like user defaults synchronization and the documents stuff is pretty well-done or pretty reliable.

That’s definitely spot on.

But for a larger/structure Core Data, iCloud has gone through the ringer, and a lot of people just sort of ditched it.

Lots of people have that problem with the document stuff as well.

Document stuff is possible to get working with a lot of trouble and work; Core Data syncing is just not possible to get working.

Is that 100% fact? [Laughs]

The funny thing is it’s easy to get it started, but then you’d start to realize that in goes all these cases where, “What if somebody signs out, what if there’s no network, and then they sign in with a different Apple ID,” there’s just so many use cases that we, as developers, have to care about that.

It’s painful.

Yeah.

From my perspective, I think iCloud Core Data just never even interest the picture because we typically build apps that have a web component or an Android app as well. So immediately, iCloud is off the table. It’s interesting to me that – I suppose I’ve been fortunate that I haven’t had to tackle those problems – a lot of times, we’re building our own APIs so we’re in-charge of defining both ends and making sure that synchronization works.

I think the reality of it is that as much as we’d like to ignore Android and other platforms, we really can’t. And you’re right; web is a really big component to apps making it feel harmonious.

When we’re talking about scalable cloud services, are we talking about using other systems like Amazon S3 and then hosting your own stuff? Or, do you usually just recommend people go with something like these hosted services that are out there and kind of ready to go?

I think I know a little bit more about Pragmatic as I age here. I used to doing the hacking thing, getting on my own app running. But more and more, the reality becomes that it’s hard to do an app right on the server and get security right and get the synchronization working right. Synchronization seems simple, but it’s one of the hugest issues in programming today I think. So I kind of like to use other service so I don’t have to worry about it as much. That’s where Amazon is a great service especially with EC2, but you have to be fairly aware of the infrastructure behind it, unless you’re using one of their database services. And they do have an API, but I found services that provide the whole thing, an SDK, to make your life easier like Parse or even Microsoft has an Azure mobile client that you can use with your app.

What do you look for in a service like that?

Something that has a good free tier, that’s honestly one of the big things. You can’t see paying out of pocket to start trying to use a service. Something that has really awesome documentation; there’s nothing worse than trying to get something started in your app and you really know where to go except for forms from the first start. Obviously, something that has a lot of street cred, other people that have used it. Something that has really great native support with an SDK for the platform you’re working it on. It’s great using SOAP…oh, not SOAP, I’m sorry…

You heard it here, folks!

Yes. It’s great using a REST Service with JSON, but I really like having native wrappers around everything.

SOAP is dirty.

Yes. That step was a very bad slip. [Laughter]

SOAP seems like the thing to do with the time.

Yeah.

Oh, don’t worry, we have an API. It’s called WebService1.asmx. [Laughter]

I have to ask then, with the services, you said you don’t want to worry about how to handle all the syncing and stuff, but shouldn’t you be aware of how your service provider does it?

Yes. I would say any service provider that tells you that sync is magical and it just works, you probably want to walk away from that. It’s sort of what we heard with iCloud. I’d like to have a little bit more introspection of how things are working and being able to put breakpoints with their SDK or being able to see the traffic on the website to monitor data. Things like Parse have a great data explorer so that you can actually see the data that’s heading their side of the whole system. It’s great for debugging and figuring out what’s actually going on.

What kinds of authentication do they provide usually?

Most of the services provide their own type of – it’s like an open off type of variance where there’s a token being pass back and forth. Parse lets you create a user object through their SDK, which you can assign custom ACLs or Access Control Lists, so that you can provide public data to your app users, and also lock down the data so that the API, should we say, the SDK provides a very easy mechanism for doing registration, forgot my password, and then trying to delete your account.

So all these functionalities, these are available to user of the app as one of their SDK?

Yes, that’s correct. Pretty much most of the good ones provide a base set of screens thatyou can use in your app to create an account, to login or to logout, and then they’re fairly customizable. Parse has done a really good job with their screens, and on Simperium. It also has the test application or as nib that you can include in your project for a basic set of screens. But ultimately, it comes down to a block-based method calls saying “Login with these credentials”. Most of the SDKs out there for services will kind of store that stuff into private areas; you don’t have to worry about remembering a token. It’s just when you bring up the library and you tell it to start Parse, it’ll know that you’re already logged in.

If I have an app that I’m backing on the Parse and you have an app that you’re backing on the Parse, I’m wondering, do I set up a different set of credentials for my system than what you set up for your system with the same user as using them both?

Yes, definitely. Everybody is in their own each app instance. If you create an account with Parse and you tell it, “Okay, I have an app, here’s my app name,” they get their own private store, a private bucket for everything that’s in your app. There isn’t a shared pool; everything’s private to the actual app instance. That also lets you create a dub version of your app so you can switch out the token IDs that you get from Parse when you created an app. So if you want to test in the area, that doesn’t affect other users. It’s fairly easy to do that.

So what is a good use case for a service like this?

The first use case that I had needed – I have a simple Migraine Diary application in the App Store and it’s just something I’ve been working on on the side for a couple of years now – I wanted to provide a way for people that had used their iPhone to do all their data entry into their Migraine Diary, a way to put that data onto their iPad so if they go to their doctor’s office, there’s a way for them to share all of their history with their doctor. I tried using iCloud to start with, and it was a very, very much of rat at hole. It looked really easy, it looked very straightforward, but it ended up being a real pain in the neck. So I backed away from that and I started looking at these cloud data providers. I found that there was a couple that really piqued my interest because a couple of them actually provide NSPersistentStore behind Core Data so that all the way through, it’s really plugging into your Core Data stack. But I wanted something that was a little bit more control over syncing the data, and I’d like to parse because I could setup my own routine to do the synchronization from the standpoint of copying data out of the Core Data into Parse. I found that that’s probably the best use case scenario – you want to start sharing the data with people’s devices that they have; it’s more than just one device. That’s really I think the most base use case for having one of these services in your app.

Aaron, we talked about kind of migraine entries, how does the SDK handle basic operations like creating a new one? Did you just get kind of quite operations? Do you have more control of what you’re doing?

Specifically talking about Parse or not, they have the base object, it’s called “PFObject”. Everything that comes out of Parse is a PFObject in one way or shape or form. So it’s really easy to just create a new PFObject; you set the fields that you want on it. Using Core Data, you can generate classes, and there has all the access or methods. The PFObject is really just kind of the key-value store. So you set whatever you want on it, you can expect the data to come back when you retrieve the object. You have to kind of manage the names of the fields, but it’s really straightforward. If you want to delete an object, you just tell the object to delete. At some point, you have to tell Parse, the API, ‘Save’ and you can have it be a blocking call, or you can tell it ‘Save eventually’, or basically save whenever. So if I’m offline, Parse will manage that object and kind of put it in an internal queue, so next time it gets the network connectivity, that object is synced.

How much control do you have over what goes on in the backend? Is that completely transparent?

From the standpoint of knowing how things are saving on the app, is that what you’re thinking of?

Yeah.

Okay. You can ask an object if it’s been saved up to the Parsed cloud, you can tell if there was an error (I believe you can do validation [unclear]), you can also ask the backend for any new objects, you can add cloud code as you can actually put a JavaScript method or routine in Parse on the website, and you can actually retrieve data through one of your routines that does queries or whatever you want. You pretty much have feasibility for everything that you put into Parse. Some of the SDK things are a little bit more under the hood. From what I’ve heard, you can pretty much poke through and listen to notifications and figure out things that are going on that you know you don’t have to care about.

Great. Yeah, very cool stuff. So you talked about the thing key-value store, what kind of querying capabilities do you have?

The querying is awesome and also limited. If you can create an NSPredicate, you can query for it out of Parse. If you’re familiar with Core Data and querying data out of Core Data, that’s effectively the same thing. Limitation comes around the number of records you can return. They have a max limit of a thousand records being returned in any PFQuery. There’s ways around that: you can do paging, you can also try to limit the number of entries coming back by some other means, you can also associate objects. I’m trying to think of a good example…on the Migraine Diary, if you have a food trigger, you eat some type of food and it triggers the migraine. If you had a relationship between that food item and all of the Migraine Diary entries that have said “this food trigger this migraine”, you can retrieve those right off that object without having to issue a query. So there’s ways to structure your data to get beyond the limits that are imposed by their API.

Is there any kind of relational functionality in all of this?

Yes.

Okay.

If you can take any PFObject and associate it with another PFObject, it just automatically associate that in a cloud data. It’s pretty easy to do.

I’m pretty comfortable with a lot of the ORMs out there that are, “You have this kind of object and it associates to this other kind of object,” is that how it works? Or, is it just, “This general object releases this other general object,” and there’s some kind of name for the relationship that it has?

No, but actually, it’s really basic. It’s going back down to the key-value type of thing. So if you have the Migraine Diary object or a migraine object, you just say, “Set trigger” and you associate that as the value, if you assign a PFObject to another PFObject, it knows it’s in relationship.

How do you know, if you wanted to receive a list of objects and sort of “join” the additional records like include the other records in the same response, can you tell it to do that?

Yup! You can just use the documentation. If you want to go download the object hierarchy when you’re issuing the query, it’s all you have to do. It’s kind of like however you would write an NSPredicate with standard objects.

If you just want to say like, “Give me the last ones, but also include the related records,” because otherwise you would get like the Select N+1 problem where, as you render each TableView cell for instance, if you then touch the property on that object, am I correct in saying that it would go fetch that from the network? Do you get all the objects and at that point, they’re sort of disconnected from Parse?

There’s a limit to how deep it’ll go. I think you can set that limit on any type of query, but I believe there is no limit to the object hierarchy, and not at least were meant to limit. But also, I try to keep my object wrapped pretty structured so that’s only like one or two levels deep so I don’t run into issues like that. But you can actually cache a query. So if you are always asking Parse for a set number of objects with the particular query, you can tell it to cache that under device. You can tell it how often it should go out to Parse to figure out, “Has this query been updated?” but it allows you to do a lot of offline things so it don’t have to do a network kit.

So what are the platforms that are supported by Parse?

Android, Windows phone, Mac OS, Edge, there’s a JavaScript library so you can just [unclear] up your UI with Parse. There’s a couple of other ones, too. You can do anything with .NET so it’s more than just Windows phone.

Yeah, there’s the Unity UI for Linux.

There’s tons of integration with other platform to Parse. They’re probably one of the most complete I would say.

One question that I have about a set up like this is when is your app kind of too much for a service like this?

I would say you problem will start running into issues with Big Data. So if you have millions of records granted, you have to ask yourself why do you want millions of records for an app on a mobile device. But in my case, if you’re trying to run something like a hospital, actually it’s a bad use case because of the whole HIPAA laws…

Right. So HIPAA is an Edge case where this probably wouldn’t be a great way to go.

Yeah. If you have a lot of existing data and you’re trying to transform that data to go into Parse to back all your mobile devices, you run into those limits; so you have the thousand rack [unclear] query. If that would affect how your app interacts with the user, that’s where you start to break down. I have seen Parse being used as an intermediary player between the real backend for an enterprise platform and then the web, those two that you can actually call services from Parse to be able to perform any type of data transformation between system. So if you can treat the mobile air as something as a kind of a temporary or it doesn’t have your entire business in there, that’s when we are kind of [unclear]. But, I have not seen a good way of handling millions of millions of rows in Parse but don’t have to do some funky things to do data.

It seems more like you’re dealing with one person’s data and you’re sort of a natural on that person it might create. Do you think that that makes it sort of ill-suited for your larger like – this is probably another terrible example – but if you’re doing something social like Twitter or something like that, it seems like it might be a really poor fit.

Since Facebook bought Parse couple of months ago, I have a very strong suspicion that Parse will become better suited towards Big Data just because Facebook is a huge object raft. I think if they’re looking at improving the service for the larger situations that some half developers need to handle, I think it’ll definitely code on the road. But I think the original use case for Parse when the founders created it was for the small app developer that needs to have a backend that just works between each of the users.

I have to say that, I do primarily Ruby and Rails for my clients, a system like this, I like having all the control but it definitely has some appeal in the fact that they’ve bought all of the issues that I don’t have to worry about if I wanted to set something up for my iOS apps.

To me, as an app developer, the thing I care about the most is offline. There’s so much you can do online that will break when it’s in an offline mode. Having a great SDK that handles offline and caching and cache expiry and all of that, to me, makes or breaks a solution. I think Parse is really a good job with giving the controls to [unclear] to ‘can-do’ things offline without having to make your app unusable.

How do they handle that? Do they have some kind of caching object or class?

There’s a whole set of files that could create it when you install the Parse SDK into your app. They have a lot of thousand whistles under the hood that handle detection of synchronization conflicts and just the offline caching in general. You have to be aware when you want things to work in an offline mode in the concept of query caching. You have to know that if there’s a query that just absolutely has to run when you’re offline that you have to make sure that when you create the query that you set the cache type and expiration on it. So it’s not completely automatic in the sense that you have to care [unclear] offline. But they do make that support very well documented in their API.

I think a key part of this whole structure that makes it I guess more of viable for like a real solution is the fact that they have a JavaScript API as well…or maybe they don’t have JavaScript. Do they have an API on the web that you can just hit from your own service? So if you did have an application that you didn’t have a server originally and you started off with the sort of Parse thing to synchronize data, then later on, when you just implement your own or migrate to and from it later, that’s a supported operation because you can hit it from an API however you need to. I think that’s kind of a key differentiator between Parse and some of these others where it may be some sort of black box that you’re putting your data into. To me, that seems really important thing to call out.

One of the times that I wanted to use Parse with one of the enterprise plans when I was working for Software Company, we dealt with a large enterprise that was very, very much stuck in like the 80s waterfall development methods. They were a manufacturing company so a lot of their development was structure on developing physical products, and that’s kind of how their software went with it. They wanted to write an iPad app to help manage the sales process for their equipment that they sell. We originally had suggested putting an intermediary later, and I had suggested Parse, but our app would talk to Parse back and forth. Our API would only hit Parse, puts them in the cloud, and then they would, on their side, talk to Parse through just a regular REST API, send it data updates or kind of [unclear] and shuttle things through so that if we ask Parse for some data and there’s nothing there, that it goes back and hits the backend just because what they called RESTful API on their side on their servers was really kind of the hodge podge mix of visual basic and C# in ASMX files. It was to the point where I would do the request one day against their API, and the JSON coming back would not have quote marks to view a single tick marks. I asked one of the developers like, “What happened? This is not correctly formed JSON?” he said, “Oh, I switched to character, I forgot,” and I phone up that they manually mapped all of their data into JSON by hand in the code; there was no mapper that they were using.

Things like that will break your app; people will blame your app, and not the backend. I think the email to separate yourself from that backend is a huge deal in mobile apps.

It’s like a firewall. So how do you sell using Parse in between layer to companies? Do they manage to just hit the RESTful API? Or, do they have made of Java or .NET type clients they can use.

If they have a .NET application, they could easily just take the Parse API and build it into their app and then provide some sort of methods that they’d push data on a scheduled base as in they pull results back from the Parse API. They can also just hit the RESTful URLs and pull the data on JSON if they don’t want to majorly impact their app development by including this third-party library because some enterprise people consider out a security concern. There was no reason why you can’t use the RESTful API just directly. It’s really easy to include it with the Java application or .NET application and have the PFObject right there.

Okay, the backend clients, .NETs, Java, do they make any other ones?

Objective C. So if you have a Mac OS app – not anybody uses web objects anymore that was Java – you can pretty much write a backend app in any language that’s being used today and they provide support for that type of language.

Okay. So what other kind of systems did you look at before you choose to going with Parse?

Let’s see, I try to think some of them. I know Heroku was one of them, [unclear] at that time, Microsoft’s Azure cloud service for the mobile client that’s just starting up so their API was kind of weak. That was more of a better solution for them because it wasn’t .NET, their developers could support that cloud application.

Nowadays, there’s kind of a distinction between Azure, the cloud-based hosting platform, and then Windows Azure Mobile Services, which is kind of a sub-set of that. It runs on Windows Azure. I spend a fair amount of time building an app on Windows Azure and it was similar to what you describe Parse as. You have a JavaScript sort of runtime on the server that you can run when you say “Insert Records”. One thing you might do this is send a push notification using the JavaScript API on the server, and you can figure that on the server so that when, say, save a record on the phone, it will execute that JavaScript on the server and send push notifications or whatever. And you have similar things there. I don’t know any high profile apps that are using Windows Azure Mobile Services, but it seems pretty robust. I don’t know, I was able to get pretty far with it. Ultimately, from my perspective, I do like owning the data and that sort of piece. But if I were to choose a platform to build a new app on, it would certainly be on my list of things to look at.

There’s actually a big button in the Parse dashboard where it says “Give me my data”. It will export everything into a JSON format and then you can just walk away then.

I really respect the companies that do that because they recognize it as important decision for you to say “You can walk away at any time”. Like kind of going back on the point you made about a free service like, “We want you to try this, we want you to experience it for yourself,” it’s kind of like money-back guarantee or whatever, there’s no risk. I think the big button that says “Give me your data”, it goes a really long way. Plus, I really actually like the Parse data browser or whatever they call it. It’s just pretty awesome.

It’s basically like DataGrid in Microsoft Excel where you can put filters at top and you can limit then all the data you’re seeing back and you can modify data on the server, just kind of scary in some sense. Limitations are object associations are hard to do in those viewers; they don’t really have a good way of doing that. But the way around it, if your association was simple, you can actually just add an NSArray as one of your properties instead of it being a separate object. That’s pretty easy to sync the data browser.

You mentioned like Heroku and Amazon Web Services, to me, those are like just as entirely different class of choices. Like if you wanted to build your own scalable backend, with those, you would end up rolling your own entire application; you do something like Rails or Node.js or whatever you want. But having built a fairly large system on AWS and numerous ones on Heroku – Heroku is my platform of choice actually just because it’s so easy to write apps, deploy and scale up and down. But I spent a lot of time on AWS for the past couple of years and it’s so incredibly complicated [laughs]. It’s not like, “Oh, I don’t need this scalable thing. Let’s just throw it on AWS,” there’s so much stuff to learn and you literally have an API for creating network cards and rubbers and internet gateways and round tables. It is truly like programmable infrastructure, which is like it’s totally different environment. If you have people who specialize in that, you can make something pretty robust on AWS, but it’s also pretty expensive.

I would agree [laughs]. One other things that, especially with a lot of people in the iOS developers, it’s pretty daunting when you see a system like that; it’s so configurable and so customizable, that’s why I picked some of these simpler solutions. Our great stepping stone, if you feel like you are going to reach a million users, it is pretty easy to go to a larger solution building your own app, hiring somebody to do that for you. So moving away from like a Parser is pretty easy to do.

I’m not sure if Simperium does this, but I’ve seen some demos of ones that were like use web sockets or long polling or something like that to do like a little bit more real-time interaction with the phone, like if you type something on the phone, it shows up immediately on the server. Cheddar is a really good example of this where Sam Soffes, he used Pusher to do, I think web sockets, where it’s like more real time interaction between device and cloud.

Yeah, I know Simperium, it’s kind of like Google way of what’s – I can’t really name the technical term behind the actual concept of that, but I know with Simperium, it will keep an open connection, it watches for changes. I just started at auto Mac a couple of months ago and I had not even really paid attention to Simperium. Now I started playing with Simplenote and I see that there’s a lot of great benefit in there. If you’re doing a real-time updates between different apps or different devices that you have, Google Way is kind of a bust, but the technology behind it still lives on quite a bit with Google. I think the Simperium SDK and API is really kind of spot on if you need that realtime updating. Even if you don’t want the real-time, just the conflict resolution and the way it handles sync is pretty elegant.

It’s good topic to talk about. What do these platforms in general offer for conflict resolution? Usually like last in wins…

A lot of them are. Some are really easy to ignore this conflicts and just kind of say, “Okay, I win; I’m the last one here syncing.” In the case where you have one user trying to use multiple devices and they’re trying to do a sync, then it makes sense that last one is the winner. But if you’re trying to do something with a group, like a group editor for a note, that’s when you have to start getting into the more complex, conflict resolution. Simperium supports quite a bit of options when it comes to that.

We haven’t gotten into the deep bag yet, but I’m impressed so far.

What are some of the other services out there other than Parse and Simperium?

I used to have a list that I maintain for myself. But there are a couple out there that I used to think were good players. But really, I’ve been sticking with the big names in data synchronization like Parse and the Microsoft Azure. I wish I could find my list here, but I haven’t actually tried to go beyond that because they’ve really been meeting my needs. Simperium is really the one that I’ve been finding that’s kind of stir in the pot for me. I don’t know. Do you have any other suggestions for things to look at?

I’ve heard a few others, I’m trying to think of them right now. Firebase is one that I’ve heard of.

There’s one called Helios with Mattt Thompson in Heroku. It looks really good.

I have some experience with Helios and it’s kind of a different offering, and that it’s all open source and you have to sort of assemble and configure it yourself. I think that it’s like a really good building block if you wanted to build your own, but you needed to start with something.

I think that one uses the AFIncrementalStore, doesn’t it?

Yeah. And AFIncrementalStore, to me, it’s this fascinating technology demo; that’s kind of the way I still view it. I tempted to use it for a couple of apps and I just don’t think it’s ready. Part of that is that your model tends to change over time, and with Core Data, you have to go through migrations and then you have to make sure that the API is in-sync, and what do you do about versioning, there’s a lot of that type of stuff. However, it demos really well if you have like a lockdown database scheme of like To-Do items or something. If your system is that simple and you can just take the Core Data scheme that you already have and drop it in managedObjectModel, drop it in Helios or rack-coredata is the one that’s providing that and it will generate a sequel database out of that and provide the API for read and write operations or basic code on top of that data. All that stuff is like really, really drop and simple. But extending it from there, like it’s not going to do all the things that Parse is going to do for you. Like for instance, adding a new attribute to one of your models or all of your models, you’re going to have to sort of take the starting points, you’ve grow it yourself. So I think Helios is a really good solution, but it’s more of in the build-your-own camp.

Actually, I always keep [unclear] about Dropbox; they have a really awesome sync API. And if you have a more document-based application, that’s probably a good one to look at.

I got turned off by that. I saw quite a bit of comments about their API documentation after they released it. It looks like it wasn’t written by iOS developers.

Here, boy. [Laughs]

There is some things like, “Perform this operation, but if it fails, you have then an error.” Typically, with those signatures, you’d have like NSError** so then you can allocate a pointer, your own pointer for that, and send that in, and then it would be populated with something if the thing fails, where those signatures were just NSError*. It just kind of a little sloppy; somebody tweeted that it looks like it’s amateur error over Dropbox, which is a little critical. But you have to put this stuff under heavy scrutiny; it’s going in your app. A lot of them are static libraries where you don’t see the code. I think it’s really important to be cautious about what you include in your app and what you decide to depend on.

Definitely. One of the other things that I always forget, the Parse, they do provide API for push notifications. They also have a great StoreKit Wrapper. So if you’re selling things in your application doing In-App Purchase, they have a great receipt system that just kind of works between the different installs for that app. A lot of the good APIs do have records around, at least push.

Very nice. So if somebody decided to roll their own, do you have any advice for them?

Rethink it. [Laughter]

I thought you were looking for the call check.

The what?

Call check.

Yeah, exactly. No. I can, but yeah. Anyway, I guess the thing is this, say you do have like the HIPAA requirements or something that kind of preclude you from using something like this…

Sure.

What kinds of things do people need to looked at and make sure that they cover?

They are definitely going to have to start looking at both the app side and also the server side. It’s not just something that they have to spend all their time on the server side and it’s just a matter of who the API calls. There’s things that they can look at like libraries. We talked about a few already, but TICoreDataSync is potentially one of the libraries that they can use internally in their app to hit custom services that they write. There are some providers like I believe some pure emails, it has the way for you to use your own server as kind of like up here on the data network. If you allowed to use Simperium but still want control of your data, you can hook on your server into their data clouds that you’re kind of appear on that whole process. You don’t own it, but you are part of it. But if you are going to write your own, you need to make sure that you understand scaling, that you have true REST services that you aren’t trying to carry state across each request. And you have to make sure that if service go offline, your users going to be redirected. There’s a lot you have to worry about especially infrastructure on the backend to make sure that you’re doing it right. And as anybody else dealt with scalable apps in the cloud and doing a bit in custom, I’m not really on that part of the team, but at next in Kiwi, all of our web apps which are a big part of our business are custom. They’re all .NET though, we host them on Rackspace.

I’ve done several things that have scaled in different ways on AWS; Heroku kind of handles the scaling for you if you want to pay them. I’ve done a fair bit of that, it’s just the other end where you do the caching and the handling all of the Edge cases. On the device, I haven’t done a lot of that yet.

That’s typically where if you’re not doing it right, the users are going to think your app sucks and they’re just going to delete it. So you have to spend a lot of time testing those Edge cases. It’s interesting that you have to literally go on site sometimes to figure out when you fade out of the network and you come back again what happens, there’s a lot to be done. That’s kind of why I have taken the approach of – because somebody else has really seen a lot of this and done it, so I try to reinvent the wheel if I don’t have to.

Yeah, that makes total sense.

Aaron, you talked about different ways that kind of different laws of control if you do your own backend service and you have to think through all the kind of sync problems. Do you have an idea of when it kind of make sense to roll your own versus use parts at kind of what level where you’re not kind of resolving things that have already been solved?

I think it really depends upon the solution that you’re trying to come up with. The HIPAA rules around data privacies really a great example. But there’s other cases where you may have a client that’s just not really keen on putting their proprietary data out there. The one client we’re dealing with the manufacturing was kind of [unclear] about using Parse and they ended up not using it in the first application we wrote for them because they were kind of doing the groundbreaking thing with their application in their industry. So they were really uneasy about putting their data in the cloud; that’s a big scary word for executives. So if you really need to have tight control over who has your data, especially if you need to remote wipe devices, you don’t want to have people pulling database off their app. If you want to just keep it on ‘mine only’, those are the scenarios where you probably want to start pulling your own team together to write a backend. But for most independent people, I can’t imagine them being at strong need for that sort of thing. JAIM: Where is the data actually stored for Parse? Do they have their own servers? Or, they use like an Amazon, something like that?

They say it’s their own servers, but I have a feeling they’ve written their services that really can go pretty much anywhere. I think they don’t really advertise where the actual data is stored, but I’m sure it’s hard to find out.

Alright, well, let’s go ahead and get into the picks. Thanks for coming Aaron and sharing your experience with us. We really appreciate that.

Yeah, it’s been great!

Andrew, do you want to start this off with picks?

Sure! I have 3 picks today. The first one is “Mac Dev Weekly”. Some of you guys probably have subscribed to the iOS Dev Weekly, newsletter email that goes out every week. This is a new one that’s more specifically for Mac developers, with some iOS content. I think he’s just still starting to get it up and going, so he’s trying to get subscribers and then he’ll send out the first issue. It’s MacDevWeekly.com. My second pick is another article on Mike Ash’s blog, but this is actually not by Mike Ash, it’s by I guess poster named Gwynne Raskind. She is like Mike, so smart that when you read her stuff, you think that, “I’m not actually a good programmer,”

This article is “Key-Value Observing Done Right: Take 2”. She actually goes through some of the problems with key-value observing and she’s written open source code that fixes some of those problems. So it’s actually an extension of some code that Mike Ash wrote a while ago. This is not a new article, but it was helpful to me this week. Last is just an article of “11 Untranslatable Words from Other Cultures” that I thought was really interesting. These are just words that don’t have translations in English, and are described concepts that are kind of funny and interesting. I especially like the ‘comorebi’, I speak Japanese, that’s a Japanese word for the light, the sunlight filtered through trees.

I work right next to a native Japanese speaker and occasionally, I will say something that’s sort of like an American colloquialism, and he’ll ask me what it means. I’ll explain it and I’m like, “That actually makes no sense when I explain it,” and he’ll do the same thing. Some sort of Japanese cultural thing that he’d be like, “Yeah, I’m laughing at it, but it’s not really funny to you because it’s a cultural thing,” that still fascinates me.

And I actually didn’t know that word as sort of mediocre Japanese speaker, but it’s a really good one. There’s bunch of others from other languages.

Awesome. Ben, what are your picks?

I mentioned that I’ve spent a fair amount of time on AWS and Heroku. But there are times when I want my own raw servers, and AWS is not something I would probably choose for my own stuff just because it’s not really considered fast or cheap. So I’m a big fan of “Linode”, I have built a few apps on Linode if you just need like one or two servers; it’s really, really good people there, really reliable. I’ve also been trying out “Digital Ocean”, which is a cheaper SST sort of copy of the Linode service – maybe I shouldn’t say copy, but you rented VPS from them and it’s really cheap. I think I have a 2 gigabyte server that I spend maybe $10 a month on it or maybe $20. Anyway, it’s really, really cheap. And it’s all based on SSTs so it’s pretty fast. Just for comparison, installing Ruby on a T1 micro on Amazon, it takes like 20 minutes or something; doing it on an M1.Large on Amazon might take 5-8 minutes, something like that so it’s pretty slow. It’ll take probably 3 or 4 minutes on one of these SST VPSs. I will paste in links to those along with my referral codes reach so that way I can get a few bucks if you sign up. Lastly, a “Big Nerd Ranch Tech Talk” on API design for mobile apps, and I thought this is really good. It’s about 20-minutes long and they talk about REST and just a lot of the concepts. It’s a good overview of what you might be interested in for API design, so I thought that was pretty informative. Those are my picks.

Awesome. Rod, what are your picks?

I’ll second Digital Ocean; I’ve used it and haven’t had any problems with it at all so it works good. My picks are: in honor of iOS 7 announcements today, some stuff to help you get going with that. There’s a GitHub project called “FlatUIKit” which a bunch of Flat UI Components especially if you’re going to try to make your iOS 6 app look like iOS 7, that can come in handy. And then there’s another project called “iOS7Colors”, which is a category on UIColor to give you some of those pastel-y iOS 7 colors. Then last week, I spent the week in Colorado and one of the things I did was horseback riding at a place called “Sylvan Dale Guest Ranch”. They was really nice, they take good care of you. That’s my last pick.

Awesome. Jaim, what are your picks?

I’ve been off the grid for a little bit, I didn’t really come up with pick, but I have an anti-pick.

I’ve mentioned I’m trying to teach berries to code iOS, it turns out, that’s not a very good idea. A berry, they kind of do mostly Android. That’s all I got. [Laughter]

Awesome. Alright, I’ve got a couple of picks. The first one is a game that I have played off and on for several years. Their newest version is version 5, it’s “Bloons Tower Defense”. You got all these towers that are like monkeys, and you can upgrade them to do different things. It’s a really, really fun game. One other game that I’m going to pick is “Fieldrunners 2”. I’ve been enjoying that on the iPhone as well. So if I’m just sitting around and I don’t really feel like doing anything work-ish because I do have Omnifocus on my phone as well, I don’t know, I whip one of those out and spend a little time on that. But I also use Digital Ocean, and I really like them. Anyway, we’ll go ahead and…oh! We need picks from Aaron. Sorry, I almost forgot you were there…

That’s okay [laughs]. There’s actually a couple that I’m going to mention, but the main 2 that I find that are useful especially for like Core Data are: there’s an app called Base, and it’s version 2, “Base 2”, it’s in the Mac App Store. It’s for browsing SQLite files. It’s almost like a requirement that you have to browse through the database when you’re writing a Core Data app to be able to debug or if the data is coming, and if things aren’t mapping right. That’s definitely one thing that I would say take a look at if you’re looking at browsing SQLite off the command-line. I know “Spark Inspector” was mentioned in the past by you guys, but one of the coolest parts of Spark Inspector I think is to be able to hook into NSNotification center so you can watch notifications fly by. That’s really great when you’re dealing with the synchronization or just dealing with Core Data in general, just be able to watch things happening. And then I’m also mentioning, there’s a Simperium-based app called “Simplenote”, which is probably a really good way if you want to see the power of Simperium; that’s a really good app to install. And then there’s also the “TICoreDataSync” for my [unclear] that I mentioned before.

Awesome! Thanks for coming on the show again. I think we all really appreciate you coming and sharing your expertise.

That’s been a lot of fun!

Yeah, thanks!

Alright, well, we’ll wrap the show up. We’ll catch you all next week!