Could airtable power my IOS app?

Airtable is not intended to be a backend hosting service like Heroku, Parse, or Firebase, but instead is primarily designed for use cases where all users will be directly interacting with the Airtable interface. Our API is useful for extending Airtable’s existing functionality (e.g. setting up a custom sync integration with a calendar app), but is not meant to provide a backend to a web app. Hope this answers your question!

@Katherine_Duh - Why limit yourselves? FB is shutting Parse down. Who knows what Google with do with Firebase (they say they’re 100% behind it, but what about all the other things they’ve shut down)?

Respectfully, it’s a matter of focus. Because we’re focused on building a great end-user database, we have full vertical control over the end-to-end experience. We can build the right backend architecture to support exactly the type of interactions and UX that we want to deliver on the frontend. In contrast, a developer-centric platform like Parse (the founder is an investor in Airtable) or Heroku carries with it an infinite laundry list of features to satisfy all the different types of developer use cases that would be built on top of it. Different customers will have wildly variant performance demands–for instance, Google App Engine must expend an immense amount of internal effort to keep supporting Snapchat as a customer, while also building out features to satisfy other, completely disparate customer use cases.

I can respect that. Thanks for responding.

A bit late, but if your target is iOS, why not use CloudKit?

As soon as I saw Airtable, I asked myself – could I replace Firebase with this?

Just my 2 cents. I completely respect everything Katherine and Howie said, and recognize that this will probably never happen :stuck_out_tongue: :slightly_smiling_face:

It would actually be quite a bit better than firebase in that it’s got a lovely (instead of clunky) built-in data admin view.

In other words, whereas firebase only provides a server-backend as a service, Airtable would provide server-backend PLUS admin-user-backend as a service.

I’d only have to write a simple app for the end-user frontend (a sandwich delivery app), because you’ve already done an amazing job of an admin-user interface. Employees log in to airtable, and see all the sandwiches ordered, and airtable takes it from there.

I’m just always on the lookout for things that streamline app development. Firebase streamlined it by offering base-as-service, and it could be quite amazing if airtable streamlined it further by offering base-and-baseadmin-as-service.

Thanks for a great product regardless!

So I am currently building an app for mobile that uses Airtable as the back end for in the office for vehicle inspections.

Parse was awesome…

As an enterprise developer with extensive mobile, desktop and back end experience Firebase and Google sheets are just way too hard to implement…so much overhead to get setup in their ecosystem.

I mean, you have to go enable the API and do this and do that and by the time you get everything going you can’t offer the app or template to anyone easily because sorting through the Google mess is not worth it…

I plan on sharing my templates and mobile app source code when I build the templates but I wish there were a way to monetize the templates and such with Airtable.

@Stephen_Hauck Based on my experience using AirTable’s competitor Podio as an app backend, I imagine that with your smaller user base, (a small-to-medium-sized cadre of relatively patient vehicle inspectors) your app will do fine. Things I built with Podio as backend were never very performant; something like FireBase was always much much faster… but with making internal apps for an organization (as opposed to consumer apps for the masses) I think you may have found here the sweet spot for using AirTable as an app backend.

Do others agree or disagree?

I’m not sure if I would consider AT to scale to 1000’s of users like the OP asked, but for smallish organizations I’m not concerned at all.

My experience has taught me that Airtable is a phenomenal interface, but it falls short if you expect it to respond like a high-performance database or even high-volume API.

If you really can’t bear to pass on Airtable’s interface (which really is stellar), but you need higher performance, look into creating a caching server that will manage your applications API request rate, caching refresh, etc. That way you can control the scalable availability of your application while still allowing data to be managed via the Airtable API.

Also, Airtable’s API has some rather limiting issues such as 100 records per request max, 1 table per request, no schema/metadata API, etc. To keep your mobile apps simple (and for dozens of other reasons) you’ll want a layer between your data and your frontend anyway.

That makes a lot of sense although just as an FYI, I’m finding that with the use-cases I’ve been trying to apply it to, Airtable starts to hit a ceiling that a more performant API could unlock.

I’m probably Airtable’s biggest evangelist in London but I see very real problems when used for meaningful applications inside companies.

1. You can’t easily create views that combine data from different tables. So let’s say you’re building a CRM and want to show a client together with who’s servicing them and then your past interactions, it’s hard to show it in a useful way

2. You can’t submit data to more than one table at once without hacks. So in the CRM example above, entering a new lead, contact and company needs either some Zaps to hack around the problem or to enter the entities into the three different tables

3. (biggest issue by far) Airtable’s extreme flexibility and malleability means that it’s very easy to break. Because there aren’t fine grained permissions and views auto-save every change then it’s incredibly easy for someone to alter the DB without meaning to. Once you’re working with 10+ tables and 10+ columns in each it’s very hard to keep the whole system robust. It’s also challenging to give users both write-permissions and access to only certain parts of the DB.

I know these are big hard problems to crack and I’m sure you’re working on root solutions however a combination of Airtable for the account owner / admin and then a bespoke app for the users / employees is a strong proposition.

I’ve experimented with building a simple Angular app to build beautifully rendered, combined views of data and to create specific read/write permissions. It’s an amazing tool for doing this but the rate limits on the API and lack of callbacks on data changes make it hard to really deploy.

I do think that there’s a really viable middle-ground case for Airtable as a back end where some people in the organisation have full access to the Airtable interface and where employees more broadly access it through a bespoke app. It would be great to be able to do that.

Best
Peter

It sounds like Airtable might be a good backend for a Progressive Web App on iOS. iOS has had support since version 11.2. Thoughts?