Swift (for ever)

From now on, we’ll always be using Swift as our programming language.

Learning Xcode (Apple’s development environment) and Apple’s programming languages can be hard. When I first switched to Xcode, it took me a while to get used to all the tools, the debugging …etc. Don’t get me wrong, I love working in Xcode, and it has developed nicely the last years, with some really cool features 😉
When I first started working in Xcode, the programming languages to use were Objective-C and C, and I have to say that once you’re used to Objective-C it is a very powerful language. Than Apple introduced Swift as a new programming language in June 2014. Swift 1, was definitely too early (for me) to start with. Swift 2 and 3 followed in 2015 an 2016, and with Swift 3 I got the feeling that it was time to switch. But you are working on this project, and it is so much easier not to learn a new language while you are developing a new App… On the other hand, you don’t want to get stuck with old code, that you’ll have to rewrite in a few years… so when do you switch?

Apple does completely support new functionality in Swift and Objective-C. But what triggered me to switch is the online programming communities, like stackoverflow … etc. Over the last year, it has become clear that most online examples are only in Swift. In general it isn’t difficult to find the matching code in Objective-C, but it is a big sign saying “switch now”. This is of course more so for new features than for older topics.

So I’m rewriting an App from scratch in Swift. Admittedly, it’s not the biggest App, and there’s some redesign on the app… but this way the coding can be a mix or “copying” existing code and adding new code.
New apps that are under development will also be refactored to be in Swift, so that all updated and new Apps will be in Swift.

So this is goodbye to Objective-C and hello to Swift. Go…


Clouds everywhere. Here comes the sun…

Using the Cloud, iCloud for Apple users, is not exactly new. “The Cloud” has been around for many many years now. As a developer you decide how you use the cloud in function of the application you are building.
A social media app will most likely be completely cloud based. A large database app with your personal information will not be cloud based and maybe not even have any data in the cloud, except for backups or something…
Apple provides possible scenario’s to handle all these situations.
* Core Data for your local database storage.
* Core Data for iCloud to sync the database over your devices.
* iCloud Drive and Files in iOS 11 to storage files in the Cloud.
* Cloud Kit, as a file transfer system between your iCloud storage and a device.

You can also use none Apple solutions because of specific features, or because you need a cross-platform solution.
Unfortunately the provided solutions are almost always just a 80-90 percent fit. The reality is that you want local storage to work fast and offline, but you still want all the data in the Cloud, and available on all your devices, the moment you switch to the device.
This means in Apple lingo that you want Core Data and Cloud Kit to work hand in hand and be synchronized automagically. But Core Data doesn’t map on Cloud Kit. These are two separated worlds. But the developer can of course make it map and match for his application.
This is how this works.
* The only through is the cloud.
* Everybody gets the latest updates from the cloud.
* Everybody updates to the cloud.
* All the data that is relevant is in the cloud.
* All relevant data is transferred to a local storage e.g. Core data.
* On your device you always work in the local storage, which than sends the updates to the cloud in the background.
This means of course that there is a lot of error handling to be done to make this work correctly. I guess that’s our job.
So this week I’ll be working on an iOS, macOS, web integration with Core Data and Cloud Kit. I’ll we focusing on our DoDone app, because the database schema is not too complex. There will be a lot of error handling 😉
I suppose this will be the default implementation methodology for the next years.