Firebase alternatives for Data Storage and Data Sync

Firebase alternatives for Data Storage and Data Sync

Data Sync is a typical recurring and typically non-trivial developer challenge. Synchronizing data in offline/online settings, like for example across eventually connected devices, is simply hard. While JSON / REST is great, building Data Sync yourself is time-consuming, risky, and typically considered no fun. Therefore, today, we take a look at the out-of-the-box Data Sync market. If you are rather interested learning about Data Sync in general, check out this article about why data sync technology is more necessary than ever.

Introduction

One of the most well-known Data Sync solutions is Firebase. However, Firebase is purely cloud based and offers no support for local data storage ( as in “data persistence above caching”) and therefore offline usage. With a huge shift happening in computing from the cloud to the edge, offline-first approaches and Edge Computing are getting more and more important. Therefore, we’ve recently taken a comprehensive look at mobile database and edge database offerings on the market. But what options do Mobile and IoT developers working on the edge have for out-of-the-box Data Sync solutions? Very few. While there are more and more cloud-based Firebase alternatives springing up nearly daily (e.g. appwrite and supabase) forcing the user into a centralized cloud setup, there is almost nothing that supports offline Data Sync and / or persistent local data storage. As our focus is on offline / edge Data Sync and local storage, in the following we add all edge / offline Data Sync solutions we know of, but spare you the wealth of cloud options only adding the established ones.

Firebase

Firebase is a cloud backend service ((Mobile) Backend as a Service ((M)BaaS)) that enables developers to build mobile or web applications without needing to take care of the backend. This includes the data synchronization, scalability, network, infrastructure challenges etc. Indeed, Firebase, today, offers many different services (e.g. analytics, crashlytics) and goes well beyond Data Sync. We are looking at Firebase from the Data Sync perspective only. Firebase was one of the first Data Sync solutions available on the market together with Parse and Couchbase, which all started in 2011 (Couchbase through a merger of CouchOne and Membase). In 2014, Firebase was acquired by Google. Incidentally, the same year Parse was acquired by Facebook to be subsequently shut down, and Couchbase raised significant funding. All three are still in use today. 

Firebase Pros and Cons

In the following, we will first look at the advantages and disadvantages of Firebase. Then, we will compare Firebase with Firebase alternatives like Couchbase, Parse and ObjectBox in a comprehensive matrix.  

Firebase Advantages ++

Firebase Disadvantages —

Cloud based Purely cloud based
Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server
Backend as a service (ease of use) Less flexibility: You cannot optimize the backend to match your app’s needs

The Firebase Realtime Database has its own advantages:

  • hosted, powered by Google
  • for pure online use cases rather fast
  • great if you do not have a strong DB background

The Firebase Realtime Database has its own drawbacks:

  • the whole DB is a huge JSON file
  • limited querying capabilities
  • no way to efficiently filter data
  • Easily disorganized, hard to navigate and search
Pay as you go, price scales with usage Cost insecurities, hard to impossible to predict
Less iOS support (stronger focus on Android) Less iOS support (stronger focus on Android)
Doesn’t work in countries that don’t allow Google
User privacy concerns***

 

*** “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)anced settings.

Firebase Advantages ++

Cloud based
– Google: large team that supports and maintains it; very low risk of the company failing; however, Google has a reputation of discontinuing products / services, so there is no guarantee
– Backend as a service (ease of use)
– The Firebase Real-time Database has its own advantages:
– Pay as you go, price scales with usage
– Less iOS support (stronger focus on Android)

Firebase Disadvantages —

– Purely cloud based
Google: vendor lock-in (no migration tools prevents you from making your app portable), you cannot access your data as it is hosted on the Firebase server
– Less flexibility: You cannot optimize the backend to match your app’s needs
The Firebase Real-time Database has its own drawbacks
the whole DB is a huge JSON file
limited querying capabilities
no way to efficiently filter data
Easily disorganized, hard to navigate and search
– Cost insecurities, hard – impossible to predict
– Less iOS support (stronger focus on Android)
– Doesn’t work in the countries that don’t allow Google
User privacy concerns: “Firebase has been claimed to be used by Google to track users without their knowledge. On July 14, 2020, a lawsuit was filed accusing Google of (…) logging what the users are looking at in many types of apps, despite the user following Google’s own instructions to turn off the web and app activity collected by the company.” (https://en.wikipedia.org/wiki/Firebase)

Firebase alternatives: A look at out-of-the-box data sync solutions

The majority of offerings for developers that handle Data Sync as defined here, are cloud-based and fall into the category of BaaS (can also be MBaaS (Mobile Backend as a Service) or PaaS (platform as a Service) or DBaaS (Database as a Service). This means that data synchronisation is only a specific part of the whole offering. 

Data Sync Solution comparison matrix – Firebase and its alternatives

Solution name Company Category Data Sync IoT / Mobile Database Type of DB Cloud OS / Platforms Languages License
Cloudant Sync
IBM (Cloudant was acquired in 2014) DBaaS
(Cloud DB and Cloud Sync)
Two-way
cloud data replication (called “sync”)
IoT
& Mobile
Cloud
database based on Couch DB
NoSQL;
distributed JSON document database
Cloud-based
replication to and from on-device data (CouchDB <> cloud service)
hosted
service
C#,
Java, JavaScript, Objective-C, PHP, Ruby
Proprietary
(CouchDB is Apache 2.0 and they integrate with several open source libraries)
Couchbase server &  Sync Gateway
Couchbase (a merger of Couch One and Membase) Cloud
DB and Cloud Sync
Sync
needs a Couchbase Server
IoT
& Mobile
Edge:
Couchbase Lite; Server: Couchbase
NoSQL;
document database
Always
needs Couchbase Server (originally Membase)
mainly
used as hosted service;
iOS, Android, .NET (Desktop/Server), .NET UWP, Xamarin
Swift,
Objective-C, Java (Android), Java (Non-Android), Kotlin, C#, JavaScript, C
Apache
2.0, delayed open source
Firebase**
Google (Firebase was acquired by Google in 2014) BaaS
(Cloud)
Cloud
Sync via Google servers
Mobile Cloud:
Firebase Realtime Database; Edge: Caching only (Firestore)
Document
store
hosted
only
APIS
for iOS & Android
JavaScript API
RESTful HTTP API
Java
JavaScript
Objective-C
proprietory
Mongo Realm Sync
MongoDB
(Realm was acquired in 2019)
Cloud
DB and Cloud Sync
Sync
(in Alpha); only via Mongo Cloud
IoT
& Mobile
Cloud:
MongoDB, Edge: Mongo Realm
MongoDB:
NoSQL document store; RealmDB: Embedded NoSQL DB
hosted
service
MongoDB:
Linux, OS X, Solaris, Windows
Mongo Realm DB:
Android, iOS
20+
languages, e.g. Java, C, C#, C++
Mongo
DB changed its license from open source (GNU) to MongoDB Inc.’s Server Side
Public License (SSPL) in 2018.
ObjectBox
Sync
ObjectBox DB
and Sync

Offline
Sync, on-premise Sync, Cloud Sync

p2p Sync is planned

IoT
& Mobile
ObjectBox Object-oriented
embedded NoSQL DB
Self-hosted
/ on-premise; hosted service upon request only
iOS,
Android, Linux, Windows, MacOS, any POSIX-system
C,
C++
Java
Kotlin
Swift
Go
Flutter / Dart
Python
DB:
Open source bindings, Apache 2.0, proprietary core
Parse
Originally
Parse, acquired by Facebook, closed down and open sourced, unmaintained
MBaaS
(Cloud)
Cloud
Sync, self-hosted or via a provider that offers Parse hosting
Mobile Both,
PostgreSQL* and MongoDB, can be used as a database for Parse
MongoDB:
NoSQL document store; PostgreSQL:
Only
Cloud, only self-hosted or via a provider that offers Parse hosting
Server: REST
API lets you interact with Parse Server from anything that can send an HTTP
request
open
source, BSD
Syncstudio
HandApps Cloud-based
sync between SQLite and MS SQL Server based in the MS Sync Framework
Sync Mobile Edge:
SQLite or MSSQL (including LocalDB or Express); Server:
Microsoft SQL
relational
/ SQL
SQL
Server; Sync / replication works via cloud only
Android
Java, Basic4Android, Windows Forms, UWP, Windows Mobile, Xamarin
proprietory,
4 licenses available: Community/Free, Subscription, Perpetual and Royalty
Free
Zumero
Zumero
LLC
Cloud-based
replication of SQL data for Mobile
Sync Mobile Edge:
SQLite; Server: Microsoft SQL
relational
/ SQL
SQL
Server; Sync / replication works via cloud only
Mobile
only (iOS, Android, Xamarin, PhoneGap)

proprietory,
annual license scaling with the number of devices

 

 

 

 

Notes: Microsoft Sync Framework (renamed Sync Framework Toolkit at some point) is a legacy open source product which MS no longer supports

* PostgreSQL vs Postgres
** There are many Cloud Sync alternatives to Firebase, we added the more prominent options and any service that also serves Edge Computing

Data Sync is no standardized term and though it seems to be in use by many big companies and most dvelopers will have a notion of what it is, the devil is in the details. So, we might have missed an important solution or taken an angle someone else would not agree with. Please feel free to let us know what to improve.

👉 Want to save this info for later? Watch the Firebase alternatives matrix on GitHub to find it easily wherever you need it.

ObjectBox DB and Sync – designed to keep data up to date across time and space

ObjectBox is a high performance NoSQL fully ACID-compliant edge database built from scratch for efficient data on and across restricted and occasionally connected devices, taking care of keeping data in sync reliably. ObjectBox developer tools are easy to use, quick to implement, and optimized for high-performance and frugal resource-use on edge devices running mobile, desktop, server, and IoT applications. ObjectBox helps developers to focus on what they love and build great applications without needing to take care of the boilerplate code for resilient connectivity, synchronizing data, and tedious DB optimizations. This cuts down initial implementation efforts, ongoing maintenance efforts, undesired problems, and data loss – therefore reducing costs and time to market tremendously. We are dedicated to bring joy and delight to Mobile and IoT application developers.

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

Flutter Databases are few. Therefore, we’re happy to take a big step towards 1.0 with this ObjectBox Dart v0.11 release, improving performance and bringing the much-desired relations support known from other ObjectBox DB language bindings to Dart/Flutter.

For those of you new to ObjectBox: ObjectBox is a superfast NoSQL object database for Flutter / Dart and here is how you can save data in your Dart / Flutter apps:

To learn about more ObjectBox features, like relations, queries and data sync, check our ObjectBox pub.dev page.

How fast is ObjectBox Dart? Performance Benchmarks

Speed is important for data persistence solutions. Accordingly, we wanted to test how ObjectBox compares performance-wise to other Flutter Dart database options. Therefore, we looked for libraries with comparable levels of storage abstraction and feature set –  so not just plain SQL/Key-value storage but also ORM-like features. There doesn’t seem to be that much choice… 

We looked at some two popular approaches: sqflite a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its technology is phased out (see below). As a third alternative we pulled in Firestore, which does not really fit as it is no local database, but would be fun to compare anyway.

What we tested

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation was also done outside of the measured time.

We tried to keep the test implementations as close as possible to each other while picking the approaches recommended by the docs for each database. We open sourced the test code at https://github.com/objectbox/objectbox-dart-performance if you want to have a closer look.

Performance Benchmark Results

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 70 times speedup in case of create & update operations. Compared to Hive, the results are a little more varied, with Hive being faster at reading objects than ObjectBox (we come to that later in our outlook), and ObjectBox being faster at creating objects, about four times faster at updates and three times for deletes. As a mostly-online database, it becomes clear that Firestore’s performance is not really comparable.

Implementation notes

ObjectBox: This release largely boosted the performance. The remaining bottlenecks are due to Dart itself and how it allows to modify byte buffers. There’s potential to double the speed if we look at other languages supported by ObjectBox. And if that’s not happening soon, we’d still have the option to do some low-level hacks…

Sqflite: a wrapper around SQLite, which is a relational database without direct support for Dart objects. Each dart object field is mapped to a column in the database, as per sqflite docs, i.e. converting between the Dart class and a Map.

Hive: We’ve tested with the latest Hive release, which is technically discontinued. The author hit two architectural roadblocks (RAM usage and queries) and is currently in the process to do a rewrite from scratch.
Update: strictly speaking it’s not straightforward to directly compare e.g. ObjectBox vs. Hive. In Hive, the high read numbers result from Dart objects already cached in memory. If the objects are fetched using the async API from disk, the numbers drop by factor 1000.

Firestore: This is totally apples and oranges, but we still decided to include Firebase/Firestore as it seems at least somewhat popular to “persist data”. It’s quite Cloud centric and thus offers limited offline features. For example, in order to use batches (“transactions”), an internet connection is required to “commit”. Also, due to its low performance, the test configuration was different: batches of 500 objects and only 10 runs.

Test setup

We ran the benchmarks as a Flutter app on a Android 10 device with a Kirin 980 CPU. The app executed all operations in batches of 10.000 objects, with each batch forming a single transaction. Each test was run 50 times, averaging the results over all the runs. This ensured the VM warmup (optimization) during the first run and garbage collections don’t affect the overall result significantly. (We care about accurate benchmarks; read more about our benchmarking best practices here.)

Outlook

With this latest release, we’re not far away from a stable API for a 1.0 release (🎉), so please share your thoughts and feedback. For the next release, we’ll add features like async operations, more relation types and some smaller improvements. We are also working on an ObjectBox variant for the Web platform that is planned close to the 1.0 release. And of course there is ObjectBox Data Sync for Flutter/Dart. If you want to be first in line to try, drop us a line, we can put you on the shortlist.

ObjectBox Swift 1.4 – In Relation to…

ObjectBox Swift 1.4 – In Relation to…

ObjectBox for Swift 1.4 makes object relations more natural and intuitive for Swift developers. For example, let’s take the teacher-student relation to Swift and how you store objects in the database. Let’s say “Teacher” is a Swift class that has a collection called “students”. Now let’s say we have a new teacher with new students and want to store them in the ObjectBox database. It’s done like this:

let yoda = Teacher(name: "Yoda")
yoda.students.append(Student(name: "Luke"))
yoda.students.append(Student(name: "Anakin"))
try box.put(yoda)

This is pretty much standard Swift. A single put command is enough to store all three new objects in the database (sorry for the “try”, Yoda, but you know, IO…). Now let’s see how this works. The students’ property in the Teacher’s class is of type ToMany<Student> and works like any Swift collection. This is because ToMany implements the protocols RandomAccessCollection and RangeReplaceableCollection. Under the hood however, it tracks all changes. Thus, when ObjectBox is instructed to put Yoda in a box, it also knows that two students were added. It also knows that our two Jedi students are new and thus puts them in database too. If you supply students that have been already persisted, it won’t put them. You can also mix new and existing objects.

Version 1.4 does not only bring TooMany (sic) improvements, but also brings a couple of new features, e.g. a bulk-get and read-only stores. You also may have heard of Sync (some kind of teleportation for objects, my young padawan). We’re still working on that, but we started to expose the Sync API with this release. It doesn’t come with any (space consuming) implementation so it’s really about getting early awareness and feedback. A full changelog is available at the docs.

So, time to start your (cocoa) pod again and let us know what you think. May the for… um, OK, that’s getting too many references for one article. One to many.

MoodSpace Mobile App Use Case

MoodSpace Mobile App Use Case

Ian Alexander

Co-founder, MoodSpace

We speak with Ian Alexander, founder and lead developer at MoodSpace, a beautiful app making mental health exercises accessible to everyone. MoodSpace was released in 2019, and has over 150k+ downloads. The COVID-crises highlights the importance of digital support for wellbeing and saw MoodSpace surge. After trying several databases, Ian settled on ObjectBox because of its high performance and ease of use.

Alyssa: Hi Ian, thank you so much for joining me and for using ObjectBox. Let’s start with the basics about MoodSpace and your role there.

Ian: Hi, Alyssa, thanks for having me. I’m the software developer, founder, and runner of the company – a jack of all trades. MoodSpace is an app that teaches concepts from mental health. There is a massive problem with accessibility to mental health. In the UK, for example, you have something like 1 in 4 people that have some sort of mental health problem, but only 1 in 113 go through therapy and complete it. So our essential goal is to take concepts from therapy and bring them closer to people, teaching them techniques that they can do on an ongoing basis. There’s no end date like in therapy, no waiting list, and it’s a lot easier to use it in places where you wouldn’t necessarily have access to a therapist. In the western world it is much easier to access therapy, still difficult in some ways, but much of the world doesn’t have that benefit. So that’s the goal we’re trying to reach. We started last year, we released the MoodSpace MVP in September, and now we’re going through the next stage of trying to raise our next round of funding – it’s quite exciting.

A: That’s great, congratulations! Can you tell me a bit more about your team?

I: We’re based in the UK, and in terms of the technical side, it’s just me. We also have various other roles: designer, copywriter, and another co-founder who handles much of the business side. But in terms of technical, it is just me for now. Hopefully after we get funding, we’ll be able to expand the technical team..

A: What’s your background, what did you do before MoodSpace?

I: Actually, I was originally a chemical engineer – I worked in oil & gas for a couple of years, but then I taught myself to develop and for the last 5-6 years, I’ve worked across a lot of startups, for example the dating app Once, when they were just starting up, also ITV, and then started on MoodSpace last year. Moodspace has actually existed for quite some time, it started as a hobby project of mine about 5 years ago.

Moodspace Mobile App Use Case

A: There are other mental health apps out there, what makes MoodSpace special?

I: If you look at apps in the space, they’re generally fairly small and limited – they’ll have maybe 4 or 5 exercises. Versus the realm of therapy, which has literally thousands of exercises. Any app that exists at the moment takes just a fraction of a percent of therapy and tries to teach it. Our USP is that we are a very technically minded team, and with new technologies which have come out along with our internal processes, we can make a much bigger app, building something far bigger than what currently exists, much cheaper and far faster. Our USP is strangely, less about the app, and more about our process and the technology that we use to make the app. The tech we will be using is Kotlin Multiplatform, which is a cross platform framework which lets us maintain a single codebase which enables us to build fully native apps with full access to native APIs. 

A: It sounds like the app is quite comprehensive – who is your target audience?

I: At the moment, we haven’t hit the product-market-fit stage. We’re still figuring out who the typical user is. We find that the unique art style of our app has helped our growth so far, we often find a lot of people sharing screenshots of the app on social media. So we seem to have hit a niche, but we’re still figuring out what that niche is!

A: Do you have any direct interaction with your users?

I: Mid-last year, I put a survey in the app, so after using it for a certain time users get the survey. There are some questions like who you are, why you are using it, and they gave us way more knowledge about who is using it and what they use it for, which was very helpful. Apart from that though, it is very difficult to know.

Moodspace Mobile App Use Case
Moodspace Mobile App Use Case
Moodspace Mobile App Use Case

A: Yes, it can be very challenging, we’re familiar with that struggle at ObjectBox as well. Switching gears a bit – I’d love to hear a bit more about how and why you ObjectBox.

I: As I mentioned, MoodSpace is about 5 years old, so it’s gone through several databases. One of them was really time consuming to make – it wasn’t ORM based, so you had to write a lot of stuff yourself. Then the next was an ORM called Sugar, but it stopped being developed – it was a side project by someone, so maybe I shouldn’t have used it in the first place (laughs).

I: So then we switched to ObjectBox, and actually the reason we switched was essentially to skip asynchronous code – I’ve always been a frontend developer and what I’ve come across is that asynchronous code makes things very complex, and it means app development takes much longer. Because we had a lot of time constraints and we wanted to develop as much as quickly as possible, I actually wanted to completely skip asynchronous code – which I wouldn’t recommend – but essentially ObjectBox let us do that because it’s very fast. You’d have to have a ton of data in the app, before it would visibly slow it down – and I did a lot of testing around that and it would have needed several years of data before noticeably slowing down the app. So, that was our original reason, perhaps a bit of a strange reason. And we’ve since changed the app so it’s asynchronous, so it won’t slow down any longer, no matter how much data you add in the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: What features in your app use the database?

I: Actually everything is in the app, as we don’t have a backend. So we need it to store all the data in the app.

A: Okay, sure. Keeping everything in the app is also practical from a data privacy standpoint. How did you actually find ObjectBox? 

I: It was someone I used to work with at Once – they used greenDAO and mentioned that ObjectBox (by the same people) was coming out. I looked into it a little bit and wanted to use it for a while, but it wasn’t I started developing MoodSpace again that I had a chance to. 

ObjectBox is very fast, it would have needed several years of data before noticeably slowing down the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

Moodspace Mobile App Use Case

A: Are there any other developer tools that you’re excited about and would want to share with the community? 

I: Yes, Kotlin Multiplatform. Having been an Android developer, having used Kotlin for quite some time and having tried cross-platform tools before, I think Kotlin Multiplatform will change the way you make cross platform apps, because it lets you share so much of the code base without sacrificing the native experience. It has the potential of leading to massive cost savings in app development. Maybe in the next year or two I can see it having a huge impact on frontend development across mobile, web, and desktop.

A: What are your big picture goals for MoodSpace? Upcoming milestones? Does ObjectBox help with those at all?

I: Actually, it potentially will, with regards to ObjectBox Sync, which is part of my plan for that app. The app right now is only available on Android, and providing we get our next round of funding, we are going to be adding iOS – where we’ll need some sort of backend. We want to avoid, again, spending much money, and one of ObjectBox Sync, Realm Cloud or Firestore can help us do that – obviously as ObjectBox Sync is nearly ready, we’d want to use that. The main point around that is cost saving because it solves a lot of problems that otherwise we would have to solve ourselves – things like offline access and syncing with an API, that would otherwise be very time intensive.

A: Ian, thank you for your time and sharing more about MoodSpace and working with ObjectBox. We wish you the best of luck with your fundraising round!

The swift database – ObjectBox Swift 1.0 Released

The swift database – ObjectBox Swift 1.0 Released

Update: newer versions have been released. Check the changelog.

ObjectBox Swift 1.0 is here! Since the first public alpha released 10 months ago, we’ve worked hard and made major changes to put Swift first, tune the performance, and iterate on the API. We hope you love the result and appreciate your feedback.

All of this, to bring you the features you expect from a database, but more importantly – the features that we think delight developers and sets ObjectBox apart from other databases out there. Let’s swiftly (cheap pun intended) dive into ObjectBox Swift 1.0:

Built with Swift in Mind

ObjectBox isn’t just a database bolted onto Swift. Your database entities are regular Swift classes or structs that you devise. No need to subclass a particular class (as with CoreData’s NSManagedObject), nor to write tedious serialization code. ?

All you need to do is add one property for the unique ID, build your project, and ObjectBox’s code generator will write a little bit of code for you, just like the Swift compiler does for Codable objects. All that’s left then, is to call a simple method like put() on the object to write it out:

We’ve tried to keep this simplicity throughout the Swift binding, e.g. making it very easy to use any RawRepresentable enum without writing any conversion code.

Automatic Schema Migrations

A common chore with databases is schema migration. ObjectBox takes care of that. If you add a new property or class there are no additional migration steps required. Old objects will keep working, and new objects will be saved with the additional fields. Similarly, adding new classes will add them to the database without any error-prone migration steps.

Moreover, you do not need to maintain a dedicated schema, because your classes and structs are the schema in the first place.

Relations

To ensure ObjectBox knows how to save object references, you use a wrapper class. Either ToOne or ToMany, instead of a straight reference or an array. This lets ObjectBox lazily load the related objects from the database, only when you’re actually accessing a related object.

The Swift 1.0 release brings you our complete set of relations: One-to-many, many-to-many, and their corresponding back-links. ToMany behaves just like any other Swift collection, you can add or remove objects as you please with your familiar methods like append().

Queries

Of course ObjectBox lets you perform queries to collect data; either complete objects or individual properties (basic Swift data types).

But with ObjectBox you don’t mess around with query strings or unpack data from cursors. You simply write Swift expressions with function calls and operators you’re already used to.

Also, you get to keep the type-safety guarantees and compile-time checking. So you don’t have to spend hours figuring out why your query doesn’t return the proper results, just to discover you made a typo in a field name in a query string.

ObjectBox lets you then operate on these objects, watch a query for changes, retrieve the results, delete the objects matching a query etc. The source code even contains a file that adds Combine support so you can integrate with its pipelines to take advantage of Apple’s newest technology.

Open Source Swift Binding

If you’re curious how things work behind the scenes, feel free to check out the Swift source code. The Swift database source code, as well as our code generator based on Sourcery, are available among other projects through our Github account.

How-to Get Started

It’s a matter of minutes to get started with ObjectBox. Check our setup instructions (based on CocoaPods) and jump right into code with the getting started guide.

Your Feedback. And what’s Next?

As always, we would love to hear your feedback! Do you like ObjectBox as much as we do? We put our hearts in this product and are excited to learn your thoughts: What features are you most excited about, what are we missing?

We haven’t written much about a topic very dear to us: performance. We will cover this in a follow up post. Also, look forward to our ObjectBox Swift 1.0 benchmarks, which we will release soon including the sources.

——

Looking for a fast and simple data synchronization solution?


billiger.de Mobile App Case Study

billiger.de Mobile App Case Study

Arne Jans

Arne Jans

Software Developer, solute

Vivien: Hi Arne, great to talk with you today. Let’s get started by learning more about you and billiger.de.

Arne: Hi Vivien. I’ve been doing software development for more than 10 years, and API design for the last 5 years. I am currently responsible for mobile development for billiger.de, the most widely used and award-winning price comparison portal in Germany. We’re especially proud of our data security, which was just recently awarded too.

The company behind billiger.de is solute GmbH, which is based in Karlsruhe. They also have a few other brands: shopping.de, an online shopping platform for men and women, and friends communication, an online marketing agency. At billiger.de we’re about 150 employees.

Some of our stats:

300,000+

active daily users on billiger.de

500,000+

app downloads

70 Million

prices in the database

22,500 Shops

comparing 1M products

So clearly, the database and its performance on the server side is very important. Companies update their prices all the time, and on top there are all kinds of vouchers that can be applied. All of these are changing frequently – and you never know who updates their prices when. So, you can see the challenges – from a technical standpoint but also for consumers. It is hard to get the best price.

V: Tell me more about the billiger.de app – why did you decide to go for a native app?

A: Well, to be honest there was an existing native app when I came into the company. But aside from that, it’s essential for UX. We also need some offline capability for features like the notepad function or when users are in the store without an Internet connection and scan barcodes. Once they are online again, the query goes to the cloud – and the user gets his result.

V: So are most of your users on the app? Or rather web?

A: We definitely still have more web users, but user numbers are shifting to mobile more and more. Also, our web users are often one time users only. Our loyalty rate is much higher with app users, so we are trying to increase app installs. We’re seeing that – even on the web – the majority of users are coming from mobile devices. Therefore, we relaunched the website a couple of years ago to be responsive and mobile optimized. So we are focusing more and more on mobile, on both the website and through the app. 

V: Why did you need to implement a local database? How is it implemented in your solution?

A: We need data persistence mainly for certain features. We’re still using SQLite, but it’s too much boilerplate code and too little fun. We have been using an ORM on top of SQLite until recently, but it didn’t work well in combination with Proguard on some Android versions anymore. So it resulted in lost data. We’re currently using ObjectBox in the billiger.de Pro version and in a fun new project called PricePretzel, which gives users the best price actively and tracks savings. In these projects, ObjectBox has proven its worth, so we want to migrate the billiger.de app too. 

V: Yes, SQLite with an ORM can get very messy. So, why did you choose ObjectBox as the alternative?

A: I looked at several SQLite alternatives and ObjectBox looked interesting. The main decision factors were: ease of integration, stability, and performance. But ease of use and integration were really the most important factors. Stability and enough performance were rather basic necessities. We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

ObjectBox database mobile app case study
mobile app database case study
mobile app database case study

V: So did performance matter to you at all?

A: For our needs, performance was secondary. Obviously the performance needs to be good enough, but we do not have super high requirements regarding performance.

V: Do you do any sort of synchronization

A: Synchronization obviously is a super interesting feature and we are keeping an eye on it once it is publicly released. From the setup we have, we would need to do it with a connector to our existing database. Currently the web data and app data are separated and we are working on integrating them. So, this needs synchronization. 

V: Which other tools do you use in your solution/are you excited about?

A: Retrofit from Square, a networking library, we recommend it to everyone and it works super well with ObjectBox. Both libraries work well together with our business objects. Retrofit fetches the fresh data from our servers and deserializes it into our business objects, which are then persisted with ObjectBox without any additional boilerplate code.

V: billiger.de has over 500.000 downloads and about 4 stars on average – how many daily users does the billiger.de app have? Do you have peak times?

A: Obviously holidays like Christmas and Easter are busier. During the day, early evenings get the most traffic – about 1000-2000 daily active users in the billiger.de app, 200 in our Pro-app, and iOS is similar. As I shared before, we get about 300k daily users on the website.

V: Thanks for sharing, and for talking with me today. Any last words?

A: Thank you for having me! I am looking forward to do more with ObjectBox and am very excited about what comes next!