Twitter Space on Storage options on iOS

Stefan Blos: And welcome everybody to two days, space on storage options for iOS apps, we will have a little bit of an agenda. So we will describe to you what the goal is what we want to talk about today. Then some options for storage, we will share the different possibilities there are, talk a little bit about the advantages and disadvantages of each. Or maybe maybe when to use which we will hopefully give you some useful recommendations in the end. And then we'll also have time for questions if there are any. So if you have something you want to want to share, or want to get our opinion on it, then feel free to leave that here in the end. But first, let's let's talk about the goal of this space are maybe let's quickly introduce ourselves. I'm Stefan, I'm developer advocate at stream for iOS, doing what it what are you doing again? Can you can you give me a quick reminder, Jeroen Leenarts: pretty much the same as you do. But I have to report the work that we the three of us. So that's a must you and me do up to the chain within stream. So I'm pretty much the team leader of the developer relations team focused on iOS, Stefan Blos: right? But I quickly forgot that sorry. Okay, so the goal of today is base is like we want to talk about the different options there are for for storage, or databases on iOS, and actually also makeovers for choice and all the other platforms in the Apple ecosystem. But it's really hard to give like overall recommendations. So we'll do our best to talk about that. But like, there's no, there's no blueprint that works every time. So, yeah, I mean, the first thing that's probably important is when Choosing Storage option, there's really a lot of factors that are playing into the correct or maybe best solution. And we'll go over them very quickly now. But the first thing is, it's always important to think about the type of data that needs to be stored. So that can be things like simple Booleans, right? So maybe you have have the user settings, the user selects whether to activate a certain functionality or not, that will that will be a Boolean, that's, that's very different to saving things like images, or even larger objects that you define. Define by yourself. So that's, that's one thing to definitely keep in mind. So what is the data you want to be storing? Either on device or or anywhere else? Jeroen Leenarts: And also, if there are, if the if it's, in fact, a single item, web not as a structured format, not like an image file? Or why not? It's like a group of objects, or values that is related to each other? Yeah, yeah, Stefan Blos: exactly. That that really, really affects the best or the most ideal way to store these items. The second point would be like the volume of the data to be stored, because I mean, it can be it can be really, really a few options. I mentioned. The settings here, for example, user settings, that can be like four or five, six, maybe in that regard, on that, that metal arm options to save. But for example, if you think of things like social network with, with maybe hundreds 1000s of users that share data, that that collaborate on things, then the volume will be way, way higher. So that will also lead to different options for storage that you need to meet to think about. And speaking of that, there's also the question, do you need your data to be accessible online? Or is it okay if it just works offline? Because that's also like a huge, huge differentiating factor for the for the ideal solution. Because offline does come with a lot of more requirements and a lot more complexity. And we'll talk about options to reduce that complexity. But this is a really important factor to keep in mind. Is there anything else you can think of? Jeroen Leenarts: Well, you mentioned volume, we mentioned structure. Also, what's also interesting is do you want to have some sort of additional features on top of your data like, does it need to be increased? In some way, is something that you want to validate in some way before you store it or when you are reading it back into memory. Also, the type of data that you're storing is very important to consider. Because if it's if it's data that has to be in some way irrelevant to European GDPR rules, or I think they have similar rules in California as well and other countries around the world as well. It's always good to be aware of what the data that you're dealing with what it actually means to you enough, first of all, do you actually need the data? Because especially privacy sensitive information, the stuff you don't store, is also stuff that you cannot lose stuff, you cannot leak and stuff that cannot get you in a compromised situation. So I always think it's, it's good to look at data. And to really consider, okay, do I need this data, in fact, or not. And then, based on your assessment of the data, make your choices. Stefan Blos: Yeah, that's a good point. Like the, the type of data that really needs to be stored, is definitely something to keep in mind. The last part maybe is, like how important is backing up your data, because for if the user will maybe maybe lose the settings, to stay with that example. I mean, it's very easy to just redo those, and to ask the user, again, to set the settings. If it's like, a few, a few values there. Like if it's, if it's a larger social, social app, maybe, then losing data is can be can be way more important. Or, for example, if you have a Notes app, where people take notes that they need to keep, the losing data would be very crucial. So it makes more sense, or it's more important to really make sure that you have a solid backup in place. Jeroen Leenarts: And also, if you're looking at data, especially if it's the users data, is it like the use case of your application is like that you store the data strictly on the device, or I storing it, at least in the context, or the influence sphere of the user. On iOS, that would be like, I use cloudkit, for like storing it sinking in between devices. But if the data is, in fact, also stored in your backends, and pretty much the recreation of the data is a matter of requesting the data, again, from your backends and maybe doing some processing on it, then that's a total different way that you have to deal with data. Because if it's if it's stuff that is from the user, for instance, their photos, I don't know. But people have a tendency that they don't want to lose those things. They don't, first of all, they cannot recreate the data. And second of all, it's it's a huge pain in the you know, where to actually be able to, if at all possible, recreate data, if it's if it's large volumes. So it really depends on on if you have this data available in another form in another way, or maybe that you can recreate it. And I think that's also very important to be aware of that the data that you're dealing with, it might be unique to the users and maybe even unique to the use device, then there's a total different way that you need to deal with compared to data that is also stored in your back end. Yeah, great. Stefan Blos: Okay, so I think I think that that's not the comprehensive list. So we didn't mention everything that's important here, but I think it already shows that it makes sense to have a clear image in mind of the things you want to store and requirements you have, before choosing the correct option, or before choosing any option. Because it can really impact the decision you make in the end. So let's let's start with some concrete options you have. And I want to, we want to really start with purely local options you have. And then we will talk about the online options or saving data online. We'll continue with that. But let's first start with the local ones. And in my mind, the most simple way to store something on an Apple device as a developer is the user defaults, right? Jeroen Leenarts: I think so. Yeah. Because it's that's just a matter of creating the object and assigning the value and it should be it should be stored already. And that's there's not much more that you have to do about that. Stefan Blos: I think the prime example for that. It's like um, Before the user settings, this is a really great, great place to save them. Because user defaults are basically just a key value store. Right? So you you select the key, you save an object under that key, and then you can retrieve it again. Jeroen Leenarts: And I think what you mentioned, there is also an important thing. It's really a location that you should store small bits of information that allow you to configure how the app behaves. For instance, do they want to? Well, name something? Do you want to have a splash screen show? When you start your app? Yes or no? Do you want to have a specific feature enabled within your app, so that, for instance, if you have a typing support to like a keyboard type thing, you probably would store in there, if you want to enable auto correct or not, that's something you want to be able to disable or enable. So really, those those those two switches, those flips that are typically in a setting screen of an application. So if people are able to configure certain things, then that's very typical to store and use defaults. Because I don't think you want to store large amounts of data in your user defaults. Because in the end, it's just a PST file on, on the storage of the device, which you can quite easily access if you have access to the device, which is in itself a good thing. But there are some limitations that you will run into if you really start storing large swaths of data in there. Stefan Blos: So I think it makes sense to, to emphasize that it's a great place to start for things like settings, or, or small, small little things you want to save. But it doesn't really scale well. So you should an apple, they're specifically emphasizing it, it's not a place to store huge amounts of data. And as you also mentioned, like it's pretty accessible for, for people if you have the have access to the device. So it's also not a good place to store sensitive data. Jeroen Leenarts: And there's no backup in place on the on the data as well, if you delete an app and reinstall it, then the use default should be gone. Yeah, that's the only exception to that is, for instance, if you are upgrading your device to a new iOS version, then you if you have a storage limitation, then Apple might suggest, hey, we can remove apps and then reinstall them again. Basically, what then happens is that only the app binaries are temporarily removed. But all the data of the app is that stays in place. So then you use default, they will carry over to the reinstalled app. But that that's a totally different and specific use case that's not relevant in day to day use, I think, yeah, Stefan Blos: totally cloning. So I think I think it's a great, great starting option. It's great to use, because like Apple has provided presenter credit interfaces for both UI kit and swift UI, so you can work with it very well. But I think we touched on the limitation to test. Another option that you can use is to basically go more more manual here and create a simple local file. So you could, for example, create a JSON file or a txt file, to just store structures that you need to store. I did that I use that because I think it it has like a great, it has great flexibility, because you can put everything you want in there. You just need to make sure that like it's while it's a little bit more powerful in regard to you can, you can more freely choose the format in which you want to save your data. It still comes with most of the limitations that user defaults. So it's still it's not really well encrypted. So it's not a good place to store sensitive data. The key trend Jeroen Leenarts: there what you mentioned that on encryption that does depends a little bit on how you configure your your app sandbox, because there are some things with those files that you can influence for instance, you can mark a locally stored file as being not backed up in in a default backup. Because a simple local file if you just write it to the correct folder, so that's I think it's the Documents folder. And if you then create a device backup my rom read or not, it's like online or with with a connection to your MacBook, then this file will be backed up in that backup unless you specify that it should not. And there are some other things that you can do to the app sandbox that you can determine at what point in time the file actually becomes readable by the system and the app and know that you have some choices there, you can basically allow once the user has entered the passcode, the app, and the file in there is accessible to the process that owns it. Or you could actually make sure that the file is only accessible if the app is active and in the foreground. So there are some really cool, specific things that you can do there that are very detailed. But it's a bit out of scope for this discussion, I think. But do note that there are some options there. And there's a lot more flexibility that you have with simple local files. But also know it's a local file that you determine how it looks. So if you mess something up in the in the file structure, or you have some race condition between two threads, then yeah, it's all new, as a developer to make sure that you deal with that correctly. Otherwise, you will suffer the consequences. Right? Stefan Blos: Yeah, the other point I actually didn't know about, about all the options you have there. So that's good to know. But yeah, go into much detail would definitely practice scope here. So it's good to know that these options exist. But yeah, I mean, we can we can sum it up basically, as we have more risks, because you have to handle everything yourself. And as you mentioned, like race conditions, or other problems with accessing data, you definitely have to know what you're doing. To just be sure to just make sure that everything works fine. Here. Now, Jeroen Leenarts: if you want to, if you want to know more about what you can do on the fire level in like the data protection, then you should look for data protection classes in the Apple documentation. Stefan Blos: That's a good point. Good point. I think the next option pretty much ties into that. Because you could also use something like a local database, something like SQL Lite, or there are other options, of course, but I think that's the most common one. Jeroen Leenarts: Yeah, a typical option that you would often hear people mentioned that is to like around without cloud syncing. The advantage of using SQLite is that it's part of the operating system, so you will have it available. The drawback, again, is that if you don't opt for using any framework to help you support or working with SQLite, you will be dealing with pretty low level, calling conventions to be able to use SQLite. So I think you have to do some C level calls into the SQLite binary. Or you can use one of the typical SQLite wrappers that is available on CocoaPods, or Swift package manager, or as a manual framework. Of course, who doesn't love Unknown: project to see right? Jeroen Leenarts: If you want to if you want to shoot your foot to pieces, then it's a pretty solid option to try that. There's a lot of things that you can do wrong there. So it's probably a good idea to use a well established and well maintained framework to help you support using SQLite in the correct way. Ben benefit is that you're in total control of the data that's being stored. but also be aware that the resulting database file that's stored locally, it's it's pretty much the same thing as a simple local file, except this inherent in the file itself, a lot more structure and a lot more stuff going on. So you're pretty much faced with the same effects of using a simple local file, that if you mess something up, if you do something wrong, it's on you. And you just have to make sure that you take care of the data correctly. advantage of using SQLite is of course that you are able to use a relational model to reason about your data and having a relational database and putting the the checks and balances in there that you could use in a relational database, it does allow you to have pretty substantial and pretty complex data represented in the SQLite file. And I know over the years, there have been companies that had their own bespoke file format. They had their own extension. But if you then would look more closely, then you will see that Yeah, but this is actually a different extension. But the file itself is actually just a SQLite file. So they were just moving SQLite files around over the network. And once you open those, it was just fat into SQLite. And you can then query the data, a lot of flexibility. But yeah, the SQLite there's a good chance that if one byte is incorrect than the entire files corrupted and you can't open it anymore. Stefan Blos: Yeah, so it's definitely another thing that it's cool to that to happen to use it. And it's it's incredibly powerful system, these relational databases. But again, you definitely have to know what you're doing when you're using it directly. Especially, especially if you, if you would not use the wrapper, or at least, have not had a lot of experience with that, then you definitely should be careful, careful doing Jeroen Leenarts: that. And of course, you would be writing SQL queries to get data from the SQLite file, which in itself has its own set of specific pitfalls, because you are dealing with either user input or input coming from the network that you are feeding into your SQL query. So you have to make sure that you do input validation there as well, if you are interposing input from the user of the network into your SQL queries, because otherwise, there are some interesting things that you might run into with side effects that you might not want to have on your code base. Definitely. Stefan Blos: One thing that helps with that is one of the most most common options you have on iOS, which is core data. Core Data is the basically the storage solution Apple provides. It's been around for I think, forever. I don't I don't know when was actually introduced. It uses Objective C under the hood for for many things, but it's been updated over the past years, quite a bit. To play nice with Swift. It seems to not have the best, best reputation. But every time I've used it, I've actually enjoyed it. So I think it's really nice. It actually, most of the time, it uses SQLite under the hood. So if you can figure that Jeroen Leenarts: storage, yeah, it's using SQLite. Most often, you can do XML as well. But I have never seen that in practice. Stefan Blos: Me neither. Me neither. But I mean, yeah, you have the options there. But but probably for most use cases, it's fine, just leave it as it is, as is. And it offers a really nice abstraction of that. So you don't have to know anything about SQLite or any any other things. But CoreData gives you a nice way to have, I think they're calling the graph, graph database, probably something like something like like that. It's a really powerful framework, it offers a lot for you. You can also, you can also use it with Cloud kit. So you can can have it as a, as a networking option with with a lot of a lot more flexibility. But yeah, I think I think it's a really great option if you need to store a lot of data locally. Because you you can definitely do many, many things. But yeah, have you used it before? Jeroen Leenarts: Yeah, we're actually using it that stream for our chat engine. And before that, I use it at a, it was in an iPad app. And that was basically we were dealing with, I think a typical customer there, when they were using the app for like a year, they would be looking at over 200,000 objects stored in a Core Data database locally. And their performance was brilliant, no issue at all. But you do have to make sure if you're scaling core data that far, you have to really know how Core Data behaves. And the biggest mistake people tend to make with Core Data is that they think about it as being a database, while actually is a mechanism to store an object graph. And if you make that distinction in your mind, then all of a sudden, a lot of the things and a lot of the concepts within core data have a tendency to make a bit more sense. But grabbing back to using it in practice. If you use core data correctly, then I think you can you can work with object models that have data of a million entities in them without issue. But you have to do things right if you want to make sure that you keep performance at an acceptable level if you are dealing with such large sets of data. It can do its biggest advantage of using core data compared to for example, a simple local file is that with Core Data you can Really, and the same for SQLite, actually, you can get bits and pieces of your entire data set in memory. And with the local file, you have to do very specific steps to make sure that if it's a big file that you don't have the entire file in memory. And I haven't, I haven't done it on Unix machines that have been programming, dealing with large files so that you have a memory mapped file so that only a small section of the file is actually in memory. Because the default, if you open a file in any operating system is this just get the file, open it up and load everything in memory, and then hope for the best that you don't run out of memory actually. Stefan Blos: Yeah. One great resource we could recommend for that, that no, you you've also also read the book is by by Dolly walls called practice called data, I think it is, it's a great resource, it really helps understand the concept as well. So I think our data is probably under appreciated, because, like you said, it offers so much flexibility, so many functions, or functionality that you can get from it. But I think you definitely need to invest some time into learning how it works. So it can have a little steep learning curve, compared to using simple things like user defaults. But I think it's worth the time invest, because you can do can get a lot of a lot of functionality from it. And it's really, really powerful. Okay, so I think we already already touched a little bit about it, upon it, because we want to jump to the online options there are for storing data. Now. The first one we already mentioned, it was cloud kit. It's Apple's cross platform solution, so you can use it on on iOS to iOS, iPad, iOS, MacOS watchOS. I think, I think that's all. And it also even even ties into core data. So you can use core data with it. So you can store the database there. In in the cloud, and sync it across devices. I actually haven't used Cloud kit yet. So I can't talk too much about it. I'm planning to use it for a side project I'm planning to do. But I think it's the I everything I've read so far, and I've heard from other people who have used it before shows that it's a great way to sync data between devices for users. So if you if you want to show or if you want to have the user have data that is shared across, for example, a Mac app and an iOS app, I think cloud kit is a is a great option to do that. Because it offers you exactly that. One limitation there would be that it's only available on the Apple ecosystem. So if you want to share data with someone on, for example, Android or other platforms, it's not really a feasible solution to select cloudkit. For that part, for the follow things described so far. It really, really can be powerful, and a great way to use. Also, one thing that that I remember is that this has been some mixed reports on on the reliability there. So some people's people had issues with, for example, syncing across devices with Cloud kit, but that again, other ones didn't mention that they everything has been working great so far, and the only great experiences so it's definitely something to have a look at to to see whether it it fits your needs. Well. Yeah, sorry, Jeroen Leenarts: meta sinking, the most issues are hit, people have issues with the automated core data to cloudkit syncing. But again, as you mentioned, there are for very good stories about that, but also very bad stories. So definitely, if you want to do cloudkit with Core Data, have a look into what it can do and how it works and what the reports are currently online. Because I would have some reservations of using core data with Cloud kits on a big project tomorrow, but that's because I'm yeah, I'm not 100% sure if it's like a reliable solution or not. But I do know that if you have file syncing for cloud kids, then it's it should be all pretty okay. And I've been using apps all the time that use Just mechanism and that has been working. Excellent. Stefan Blos: Yeah, good points. So the next option we will quickly touch on is things like Firebase realm, or also like AWS amplify. And probably Asher has a solution as well. But I haven't worked with that before. So I can't talk too much about that. But I think these are all options that use the cloud, of course, storage mechanism. Which means they are actually platform agnostic. Because for example, with Firebase, you have clients for basically all operating systems. So you have a client for iOS, for Android, for Windows, Mac, web, everything. So it's a, it's a really nice option. If you want to have something like collaborative features where people from different different operating systems have access to the same data. That's something that's that's really powerful there. And definitely something you can you can use with Firebase, or also the other ones that I mentioned. So definitely, definitely a nice thing to have. But it also comes of course, with a few with a few limitations, or at least things you should think about. The first thing that comes to my mind is something that's called vendor lock in. So for example, if you choose to go with something like AWS amplify, then you have to be aware of the fact that your data is in then in the AWS cloud. And it's not always easy to switch from that. So once the data is there, getting it out is not as straightforward most of the time. So you definitely have to think about which platform you want to use, and whether it's okay for you to stick with it. Or maybe you want to want to change things up in the future. So definitely something to keep in mind there. Jeroen Leenarts: Yeah, and with those cloud hosted solutions, it also depends, presence Firebase, if you use the I think it's fire store or something, if you use that, then you're getting a synchronization in local stores. And you get that all, quote, unquote, for free. But if you use AWS amplify, there's some complexity in there. But you could opt for the direction that you actually are querying your data from their backends with a thing called Graph QL. And then basically, the storage mechanism in the cloud is the thing that is provided to you. And then the actual synchronization, like fetching and sending the data is something that you have to do yourself in your own solutions. So with a lot of these cloud vendors, you can you can pretty much dial how much fender lock and you would want up to the API level on the cloud side of things. Stefan Blos: Yeah, that's a good point. Good point. You touched upon it. With the quotation, you get things for free? Well, yeah, all these options have a free tier. But it's also important to keep in mind that, of course, they will earn money with it. So at some point, there will be costs. So pricing is definitely something you need to think about. At its best to think about it before you select the solution, because most of them have a pretty generous free tier, which is nice to use. But once you once you break that and come into the paid system, and it definitely is important to think about how you can keep those prices low. And that's also something like if you if you are aware of that, at the beginning, you can think about that. And think of the best way to structure everything to keep prices low. So I think the the thing to take away from that is using things like Firebase realm and everything, you basically give up control for convenience. So it's, if you if you've used the frameworks before, it's it's really easy to get started with them. They have great guides, it's really, really a pleasure to use them most of the time. But of course, is like the thing I mentioned with vendor lock in. You always give up something for that which does not have to be a bad thing. But just important to keep in mind that you that you are doing that and you're giving up the control because there's also stories. I remember a blog post I read, it was a few years ago, or something was where someone was mentioning how I got a $20,000 bill from Firebase, because I fucked up with. Sorry for that, because I messed up with my settings and had a query that was actually doing doing way too much work there. So it's pretty, pretty easy to, to get a high bill for that, if you're not aware of the, Jeroen Leenarts: of everything. And especially with these large cloud providers, because they pretty much for most people's use case can scale infinitely. That also means that you can run up to costs infinitely. And quite often, if you're dealing with smaller cloud or service providers. If they see you generating like a ton of unexpected load, they have a tendency to get in touch with you, like ask you, Hey, what's happening, while Archies, like Google, or Amazon or Microsoft Azure, they'll just leave things running. And at the end of the month, you'll just get a nice, juicy bill that I asked you to pay. And there are still some things that you can can do to save your bank account. But yeah, it does. It does work in the exact opposite direction there. So be aware of that, because it's, it's quite easy to, to do some things that will actually bankrupt you as an individual. Stefan Blos: Yeah. So the last option I want to talk about here is, of course you can, you can still use these cloud providers. And I think the biggest ones are AWS, Google Cloud Azure. But rolling your own solution there. So that means, for example, AWS, they have a storage option called AZ three, where you can simply put data, but you can take care of everything else yourself. As you already mentioned, there's options like like a graph, QL, backend there. So basically, you can take care of querying the data on everything, doing offline support, too, and syncing yourself. And just having the data stored there, without using the convenience mechanisms that these platforms are offering. Jeroen Leenarts: Yeah, and especially with if you're dealing with like, self created solutions. So like most often, these three providers, you would use them as infrastructure providers, you would, for instance, either get, like, block storage with Amazon s3, or you would get sort of a cloud hosted database solution. So I think that's called Aurora, on AWS. And then you pretty much have MySQL, or PostgreSQL interface to a database that you can connect to from your, from your execution environment. So that's either a Docker container or an easy to instance, you kind of notice that my biggest affinity is with Amazon cloud solutions by now. But you would actually be implementing your own logic in for instance, Python, Django, or maybe FAPE, or Swift on the server, things like that. And having a separate database that you fully control in the sense of the schema that is like that is placed into it. And and basically work with that, because I'm one of these people that is of the opinion that relational databases are under appreciated nowadays. And I think, most most solutions that you can build as a software as a service kind of thing you can get very far with with a cloud hosted relational database, I think. And there's a lot you can do before you actually have to switch to a more document type based storage solution, like like Mongo. But yeah, that's just an opinion. Because once you start rolling your own back end solutions, there's a whole heap of different choices you have to make in how do you store it? Do you use a document store a relational store? Do you use a block storage like s3, probably a combination of two or three of these, but the complexity does and the convenience does have a tendency to go a lot higher. But also you get like a ton of flexibility and and also performance back if you if you roll your own solution. Stefan Blos: But yeah, I think yeah, I think it comes down to Again, the same, same thing with locally hosted things. So if you, if you're ready to give up convenience, you will have a lot more control over everything. So you can select the database yourself, you can select where to host it, you can select how to do syncing how to handle everything. But again, you do definitely have to know what you're doing. Because there's like these these convenience options you have for for things like Firebase or realm, you don't have that anymore. So you need to take care of that yourself. There's always, it's always important to definitely have done that before maybe or definitely know what you're doing, because that prevents you from running into any issues there. Jeroen Leenarts: Yeah, and I do know from experience that building your own backends can be a whole lot of fun. So if you're working on your next side project, or maybe even next project in your, in your contract work or your day job. Yeah, having an opportunity, as an iOS app developer, to actually get your hands dirty with something related to backend, it's, it's very worthwhile, it's a totally different way of dealing with software development. But also, there's a lot of things and a lot of insight that you can gain from doing that. And it doesn't really matter if it's, if it's like a convenient cloud hosted solution, or if it's more in the roll your own direction, because I think what you mentioned, there's the fun, it's very true. convenience and control. Those are two things that are, I think, on the same scale. And depending on how much you slide to the left, or to the right, you get more control or more convenience. And depending on which exact cloud solution you would go with, you end up on a different spot on this scale. And it's, there's a lot of choices you can make there. And also a lot of fun that you can have there. Stefan Blos: Absolutely agree. I think it's, it's great to have this insight. So if you've never built a packet before, then I can highly recommend doing this. It's a lot of fun. There are many options, like you mentioned. But like today, we have so many possibilities. You can you could even use Swift on the server, like more things like vapor can use other languages, which is also a great a great learning opportunity use using things like Python with Django or maybe TypeScript for that is really great. So highly recommend trying that out. Yeah, so I think we covered everything from from the different, different possibilities you have. So if there's any question from your side, then feel free to raise those now. We will just go over the few recommendations we have any questions, we are happy to answer them. So feel free to raise your voice, if you if you want to do that. But like, like, starting with the recommendations here, I think it's always a good idea to start small, and then work your way up. You mentioned that you're a big fan of relational databases. And I definitely agree with that. They offer a lot of functionality. They're very, very powerful. And before starting to use fence, use fancy things like Graph QL, or, like you mentioned, like document based databases, I think it's a great opportunities to start small with easier solutions, and then only work your way up if it's really necessary. And then the second one is like there's there's many, many options out there. So it definitely makes sense to think about the type of data, the volume of data, the things we discussed at the beginning of the space. It definitely makes sense to really think about what you want to store what's important there things like does it need to be available online? Is it okay to keep it offline? Is it okay? If you lose that data? How secure does the data really need to be stored? Things like that is definitely something you should keep in mind at the beginning. Because you can save a lot of pain in the nowhere when you have a clear, clear image of that in mind. Jeroen Leenarts: Cool. I think I think we covered everything that we had on our list. So I'd say if there's no questions then it's about time to start wrapping up, right. Stefan Blos: Yep. Absolutely. Then, thanks for everybody who joined. Been great discussing these options with you, girl. Thanks for checking in. No problem. And everybody have a great day. The rest of your week, and we'll talk to you in the next. Jeroen Leenarts: And if you have any follow up questions on anything we've discussed today or during another Twitter space, make sure to send a DM to me or Stefan. You can find Stefan on Twitter at Stefan J. blas. That's BL O S. And you can find me at app force one on Twitter. And we're always open to a DM or a question on a timeline. Because we really like interacting with with anybody out there, because it's all a lot of fun being a part of the iOS developer ecosystem. Stefan Blos: 100% agree. And thanks also to Amos for at least giving a reaction near at the end of the space. That's always great. Jeroen Leenarts: Talk to you guys and girls next week. Bye bye.