Yup, I think you can gather what this article is about based on the title. Up until this point, I've been developing Timeline with the intention that this was an iOS only app, which would make a younger me shudder at the thought. Yesterday I came to the conclusion that I don't like this anymore. Let's talk about that. ### Databases and cloud syncing I haven't even started to work on cloud syncing using SwiftData. If I recall correctly, the method I would want to use for cloud syncing would be using some of the user's iCloud storage. Just like the rest of Apple's documentation, it's obtuse and I would have to read and iterate a lot to understand how it works, which I was *not* excited for. Side-note on the few times I've used No-SQL databases. It's a fun novelty for a few hours, but once you get to the point of needing complex queries involving joins and references, it falls apart. I thought using SwiftData was fine. I really didn't love the syntax of preforming queries. Here's an example of an implementation of a query in a function that I wrote: ```swift static func findById(id: UUID, in context: ModelContext) throws -> [Place] { let result = try context.fetch( FetchDescriptor<Place>( predicate: #Predicate { $0.id == id } )) return result } ``` To be completely honest, I couldn't explain some of this even with a gun to my head. ### I kinda like web I really like being able to access sites on any platform through web browsers. Call me a weirdo but when I'm surfing the net I prefer to use a computer, and if I develop my app only for iOS, that means I won't really be able to access this from anything but my phone. Kinda lame if you ask me. ### Enter the "companion app" The only real downside I can think of is losing the tight coupling with the user's operating system, which my app's location data collection process entirely hinges on. My solution? Companion app. All the main functions of the app will remain on the web interface, but provide a companion app to bridge the gap between the web and OS. BANG! ### Da plan Here's what I'm thinking. Start developing the web version to the point where feature parity is there, and then nuke the iOS project, which is super sad, but whatever. Because I'm such a fanboy, I'll be using SvelteKit. We're coming full-circle, since the first revision of this project started as a website built on SvelteKit. I don't know where to shoehorn this piece into the article so I'll put it here. I think I'll still have to have some sort of data structure to "cache" data from the database on the user's local client on iOS to make it work without constant loading. What I'm eager to learn is whether or not I can preform HTTP requests in the background. What took me a ton of time to understand and implement was location features. In my location manager right now, the function that gets executed when the user moves ~10m just stores a location snapshot in SwiftData. If I could instead have it attempt an HTTP request, that would be dandy. Here's my current implementation: ```swift func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { print("locations updated") for location in locations { // i'd just replace what's in this block with some sort of // http post request to the api endpoint let snapshot = LocationSnapshot( lat: location.coordinate.latitude, lon: location.coordinate.longitude, timestamp: location.timestamp, createdAt: Date.now, systemTags: [] ) modelContext.insert(snapshot) } } ``` ### Old code and letting go of the past At the time of writing this, according to WakaTime, I've sunk 69h21m into the iOS version, which only counts for the time my fingers were hitting keys, and not the countless hours I spent reading Apple's documentation. Part of me knows it's gonna be hard for me to let go of the code I wrote, but I also know that it's the way forward. Do you, the reader, ever get hung up on letting go of inanimate things because of the time and memories attached? ### Conclusion / tl;dr All roads lead back to the web 🤠 Fuck AI Fuck ICE Stay you