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.

IOS 11

I especially bought an iPad because of iOS 11. My first iPad was the iPad2, which I did not use much. I wanted to use it for drawing, and surfing the internet, but drawing proved to be difficult with the delays, and surfing the internet was not fast enough, so I quickly returned to my iPhone and iMac. The iPad gathered dust and was not really used.

In essence, I didn’t see any use to have anything besides an iPhone and an iMac.

We are years later, and with the arrival of newer iPads, but mostly with iOS 11, this changed. Drawing with Apple Pencil is very nice, and I do use it. But drawing outside in the sun… is not as good as the real stuff with pen and paper. I use the pencil more for note taking with the Nebo app than for drawing.

The performance of the iPad is impressive. The network speed and storage is more than enough to do serious stuff.

The question is, will you use it as a serious device or only as a device for the family and kids to Google and play with…

The usability of iPad dramatically improved with iOS 11. Multitasking, powerful drag & drop and the new and better integrated file-system with extensions into Dropbox, Box etc… turn it into a serious device.

More than a faster CPU or a better or bigger screen, the usability comes from the software.

As an app developer, this means you need to implement these features as fast and as good as possible. Sometimes this is not possible, but in a lot of cases it is simple to do.

You always start with the use-case. How does the user work, what is the workflow, is drag & drop a powerful new feature or not useful in that context. Simply implementing a share function or drag & drop in every screen is not a good approach. If you have a button on your screen, it needs to be useful. If most user will never use it, remove it to reduce clutter.

So we’ll further update our apps, and will introduce some in the near future, taking in account the specific user needs on iPhone or iPad.

New, more, different

It’s been a while since our last post. I could say we are going to make up for it, but that would be a lie. It’s my intention to post more often and on a wider range of topics. Some topics may be too technical for some people. Some topics will be announcements. Some topics just about what interests us, or our option on tech stuff.
One thing you’ll not see in this blog is politics or a debate about how things are going in the world…

So, a quick update about some things we’ve been doing.
We’ve update our website with a modern look. I hope your like it.
We’ve released new versions of Concept Clock – our view on visualising time, Done – our easy to-do app and we’re about to release an update of whosthat – (who’s that) our app to add a legend to an image.
All of them have been updated for iOS 11. Some will get an extra update later on. For example the new drag & drop in iOS 11 is something that can be very useful, certainly on iPad with multitasking, and needs to be added to Done and maybe other apps.

There are also new apps coming. We’re working a Genealogy Research App for iOS.If you have ideas or an option about our apps, you can always contact is here.

See you soon!

Concept Clock – Donewhosthat


Review of an interesting year

It’s that time of the year, when we look back and reflect on what happened during the last year. No politics or other related topics, but what we’ve learned, what has changed.

If we look at the apps we sell on the App Store (macOS, iOS, watchOS, tvOS), we’ve put a lot of effort in updating and rewriting the existing apps. Some apps were even completely rewritten from scratch. We always updated to the latest OS version, and none of the deprecated items where used.
I have to say that the guidelines from Apple have become stricter, and that some apps didn’t make it, not because they didn’t work, but because it interferes with the interpretation of an Apple policy. We may not agreed with it, and we may interpret it differently, but it’s a discussion we can’t win.
This year we also experimented a lot with new technologies. With new I mean new for us. This was for example using the new Touchbar in an app, or adding complex Core Data (database) and concurrency to an app, or testing new XML-parsers, or using more Core Animation in iOS apps…
We also extended our programming knowledge and we’re more productive than ever.

Our goal has always been, to have fun first, to create apps we love. After working with Apple’s tools for years now, we can quickly prototype and develop an app for iOS or watchOS. Our macOS apps tend to be more complex, and in general provide more functionality, which makes the investment in time a lot bigger.
It may sound strange with the “mobile first” mantra of most startups, but we will invest more in macOS next year than in iOS. With invest I mean the time we will spend on developing an app. Why? Aren’t there more iOS devices than Macs?
Sure, but most people make the wrong assumption. They state that you only need 1% of the iOS market to get rich. First, if you get 1% of the market, you can also get 5 or 10%, but you’ll probably will only get 0,000…001% of the market. Secondly, the prices for iOS app are low, so you’ll earn “some” money with iOS app if you don’t get a reasonable market share. Less than 5% of iOS developers can earn a living by selling iOS apps.
On the macOS side, there are less apps, less competition, and the prices of the apps are a lot higher. A nice complex app could cost between 10 and 25-30 USD. Nobody will complain if the app works as promised. Relatively seen, it’s easier to earn some money making a macOS app. But that doesn’t mean you’ll get rich quickly.

So focus on an app you like and love, and make the best app you can make.

Best Wishes for Christmas and the New Year.

Does it need explaining?

Last week we released a new version of (the) Concept Clock for iOS. In this version we added the ability to add custom backgrounds and custom colours for hours, minutes and seconds. We also added 2 new clocks (Rothko and Snake).
Concept Clock visualises time with changing colours, shapes… We realise that it’s sometimes not so obvious how the time is visualised, but we think that’s what it makes a (little) challenge to find out. But on request we’ll explain (most) of the clocks below.

Changing blocks: the height of the blocks become bigger as the hours, minutes, seconds increase.
Numbers and circles: the current number for hours, minutes, seconds are selected with the corresponding colours.
Rotating blocks: the blocks for hours, minutes, seconds rotate over an angle of 90 degrees. Straight up is 0 or 12 hours, 0 minutes… and 90 degrees is 11 hours, 59 minutes…
Gradient and rotating numbers: these don’t need an explanation.
One line clock: this shows the hours and minutes. Hours is shown as it would be in a normal clock. The minutes is like a progress bar inside the hours bar. 30 minutes is 50% progress…
Circle segments: a bit like a normal clock, but the center around which h,m,s rotate is different. Basically to have a nice visual effect.
Circles: instead of a line, circle paths are used to indicate the time.
Rothko: like a Rothko* painting. The hours and minutes texts move from left to right. 0 or 12 hours to the left of the color blocks; by the time it’s 11 or 23 hours the text has moved to the right of the color block. Same for minutes…
Snake: hours is shown as it would be in a normal clock. The rotation point of the minutes arm is always at the endpoint of the hours arm. The rotation point of the seconds arm is always at the endpoint of the minutes arm. This makes it like a strange snake…

Question: should we make this into a macOS screensaver?

*Mark Rothko


Bummer. Last week we told you we decided to make a cyou viewer for macOS, and we did, and it works great. And yes we submitted it to the Mac Store. There is only one small problem. Apple will not approve the App because they feel the implementation is not according to the iCloud Guidelines. The guidelines – which you don’t read until you have to – state that iCloud may not be used as a file transfer system. Of course saving documents on an iOS device, and switching to the mac and back while you are working on a document is not considered as file transfer, but more as synchronising… I understand what they mean, but the line is thin. The cyou viewer just gets the images stored in iCloud, and they see this as an App that mainly does file transfer.
Anyway, we’ll put this project on hold for now, and have a look at it some time in the future to figure out how to get around this. On the plus side, we implemented the touchBar and now know how to do that 😉
This weekend I’ll work on a Concept Clock update, hoping to have finished it in the beginning of next week. For the next week, there are some prove of concept tests planned, which have to provide some insight in how to implement some heavy multi-processing tasks in a Mac App we are working on.
Much to learn, many challenges… but that’s what we love.

Have a nice weekend.