How swift is the progress

In my last blog I talked about switching our development completely to Swift. So how does it go.

To be honest, better than I thought. A good book and documentation helps of course, but it’s easier and more transparent than I thought. As explained in a previously, I’m rewriting an an existing app, which makes things a lot easier. You don’t need to think about the business logic, so you can focus on the code. In this app, you encounter all the typical code, you’d use in other apps. The if…else, for..loop, Core Data fetching, error handling… etc… You quickly get used to the different syntax, and fortunately the syntax is very consistent and logical.
I do write the code in an Objective-C like way. One of the requirements of Objective-C is that you need to explicitly specify things. A NSString is an NSString and not an Array or a NSMutableString. In Swift you don’t need to do this, but I do specify it in most cases, just because I find it easier to understand. An other way to do this is giving a variable a name that corresponds to the content and it’s type. For example dateString or dateArray… anyways, things are going fine.

Next up is building a web app. The iOS and macOS apps both sync data to iCloud using CloudKit. So now it’s time to have a full functional web app, that more or less matches the iOS and macOS functionality. For this we’ll use CloudKit JS and build a web app with data binding and responsive design. This will take some time, because we haven’t got a lot of experience in this domain. The world of web development keeps on changing very quickly. Frameworks that where popular last year didn’t always keep up and are dropped by developers. This is the a world where you can’t predict what will come next, in contrast to platforms from Apple or Microsoft.
So the challenge is on. I’ll give an update in a few weeks…

Have a nice weekend!


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.


Launch_doneIntroducing Do-Done, the human to do list app.
Yet another to do list app I would say. So why the heck would we do it?

Have you used to do apps? I have. Lot’s of them, and none of them work the way I want to work. They work the way a program works, and that’s the main reason we made this app. Maybe nobody works the way I work, and that’s fine, but I don’t think I’m an exception.

So what didn’t I like about other apps?
1. I always have to fill in too many dates, info…etc.
2. They don’t force me to cleanup my to do’s. I’m lazy just like most people, and eventually end up with a list of tasks that needed to be done in the past… so I tend to start another (new) list that I also don’t follow…
3. Most apps don’t allow me to say that I’ll work on it, the next time I’ll work on the project. On some projects I only work in the weekend; on others only on Wednesday; on yet other projects every day of the week. I just want to be able to say – not today – I’ll to it on the next day (I work on this project).

All these things can be done with Do-Done. But Do-Done will NOT allow you to have tasks in the past! You can not do things yesterday, so you have to decide what to do with these tasks. Delete it, because it’s not important (or already done); move it to today because you’ll do it today, or move it to the next (work) day, next week, next month… It’s that simple.

Yes you can set due dates, but you’ll probably only set them when it is a real requirement.
For the rest, you can do the normal stuff like making projects… Here you can say on which weekdays you work on a project.

The icon of the app represents a Calendar with an arrow, which is not straight, as you are always moving tasks to tomorrow, next week… In that sense it might have been better to call the app Do-Move-Move-Do-Done or something like that 😉

You’ll find the app on the AppStore under DoDone. Try it out!


Starting with iCloudKit…

icloud_icon_2015-100607656-largeIt’s not that we didn’t do anything with iCloud before, but it has always been an add-on. Most apps we developed for Mac or iPhone, iPad have used iCloud in some way. But it was always a way to transfer data from one device to another, like iCloud Drive, or shared settings between iPhone and the Apple Watch…

With the arrival of Apple TV, Apple (once again) stressed the fact that they expect the apps to retrieve the bulk of their data from the cloud. In our case this is mostly iCloud.
For the less technical people, iCloud provides 4 basic ways to work with the iCloud.
1. Settings (NSUserDefaults): a way to share a limited set of data between apps with the same iCloud account.
2. iCloud Drive: a way to store documents in iCloud and open, save, close and delete them in any app. The documents are linked to an iCloud account.
3. CoreData: a database that can be used and synchronized between apps on different devices (using the same iCloud account).
4. iCloudKit: a transfer mechanism to store data in iCloud, and access the data from anywhere with any app. The data can be public or private (using an iCloud account).

The first 3 options basically are all about your data, linked to your iCloud account, and sharing them over your devices. iCloudKit is a way to publically share data with anybody, but also make a subset if the data private.

So is it too late to start with iCloud? No, of course not! It is a bit different for the developers, because you never know when or if a server in the cloud will answer. Your design has to take other things into account and you keep the complexity as low as possible 😉