My model is not like your model

I’m not talking about models in the fashion world, but Machine Learning (ML) models to use in Apps. Everybody knows Artificial Intelligence (AI) and ML are on the rise, and it is becoming easier en easier to use it in your Apps.

Last year Apple introduced CoreML, stating that the programmer doesn’t’ need to know anything about ML/AI to apply it in Apps, and that’s correct. It is considered to be a black box. You input something, and you get an output. What and how the black box gets to the result is “magic”. For example, you input an image of an animal, and you get the name(s) of the animal(s) back. You input an image of a person, and you get the sex of the person back. You input a text, and you get the keywords back…
As a programmer you can use the existing models, which are mostly trained models. The results you get are as good as the model. Let’s say you get a model that was trained to recognize a list of objects. This means that the model will potentially recognize all objects that you specified. If you didn’t specify a bicycle, the model was never trained for it, and the model will never recognize a bicycle. This is a fixed model that doesn’t learn. The down side is that the users of your App can not teach or train the model to improve. In a lot of cases this is absolutely no problem. If you do need to train a model, this stops being a simple black box, and does require the programmer to know more about ML and AI.

For the simple programmers, like me, you try to find existing, trained models you can use, and you quickly see that there are not a lot of them. So you have a few options.
1. Find a model and convert it to your model if needed
2. Use an only, in the Cloud model, and connect to it through an API
3. Make your own model

Finding a model can be hard. There are differnt model formats out there (Caffe, Keras, Watson…) and converting them to, in my case mlmodel (Apple) is a challenge. You have to install stuff and use Python tools hoping to get a mlmodel you can use. I have to say this is a difficult step if you do not know how these model are setup. In this case the convention of the model is much more difficult than the implementation in the App. I hope Apple will make this easier.

More and more ML/AI Model Stores become available. Most allow you to access a model that is hosted in the Cloud. In general you pay for the CPU-time needed to process the request. For the developer, this is an easy solution, as we are used to connect to services in the Cloud. The down side is that you have to be connected, and you may sent a lot of data over your mobile connection, which costs money.

If the model you need is very specific, but not complex, you could train a model yourself. For example, you want to recognize different types of bicycles… There are more and more easy to use tools, that allow you to make a model and train in. Several desktop and Cloud solutions are available. Most of them are focused on one platform (iOS, Windows, Android…) or another, so be careful which one you use.

If you look at all this, you see that there is an emerging market for models to use in Apps. There is a need for specifically trained models, and it will become more and more easy to train a model with your data. As this is an emerging market, it is “normal” that there is not yet a good standardized approach to convert one model to another. But as this is all quickly falling into place, future Apps will be able to do new and amazing things.


The life of a developer

Looking back on last year, I can say it was a very interesting year. There were complex projects and a lot of new tech to learn.

I think the most used tech term in 2017 was AI (Artificial Intelligence) or more specifically ML (Machine Learning) and it’s siblings like neural networks… I’m not going to explain AI or ML here, there are a lot of sites that can explain it better than I can, but I do want to talk about the perception of AI and developers to the general public.

Developers are often seen as these nerds that type stuff in the computer to make it do what they want it to do. Developers are also these people that cause all the bugs, or don’t understand what the user wants. They are the reason why your app doesn’t work, or does work the way you want.
AI is presented as the magical solution to fix all this, and developers will not be needed anymore… In some presentations AI is this thing you talk to that will figure out what you want, and will take care of everything. Well, good luck with that.

From experience I can tell you that most users have a hard time explaining what they exactly want. The way people explain what they want is full of pre-conditions, assumptions and limits that are so obvious to the person in question, that it is never explained or even listed. An App needs to know these assumptions, limits and pre-conditions, otherwise it will not work or work badly. What I’m saying is that when you can not provide a framework, a structure to an AI, it will result in a disaster. Maybe developers will become more like business analysts, I don’t know, but I do know you need to understand the process, the flow, the logic of an App for it to work.
Unfortunately, we see the opposite trend with users. More and more users only know their little part of the process, and not the whole picture. For an AI to write an App, someone will need to tell it what to do… For a super easy app this may be an end-user, but for more complex apps… I’m almost sure it will need to be someone else.

2018 will be great for developers. It will be interesting on all fronts. Developers will be needed more than ever. AI, AR (Augmented Reality) and ML will be more and more integrated. IoT (Internet of Things) will take of. BlockChain implementations will become mainstream… and so much more. Business analysts and developers will be in demand.

Have a happy and wonderful year.

MacOS and Swift 3.0

About a month ago, I started working on converting an iOS app to Swift 3.0. The iOS app was basically converted a few weeks ago, and additional functionality has been added. The macOS version didn’t exist, so I started from scratch. One of the most important reasons I’m doing this exercise, is to test the CloudKit synchronization over different device and platforms. Not just as a proof-of-concept, but as a completely functioning solution. I already got the synchronization working between my iPhone and iPad, but with the Mac it didn’t work.

Years and years of developer info on stackflow often helps, but for Swift, you better specify that you want swift 3 examples and even than you will mostly get iOS code. With Objective-C you mostly get iOS code as well, but in the case of Swift 3, this is double so.
So you download examples of Apple and others; you look at wwdc videos to see what you missed…. nothing. This should work!
So what I usually do, is continue with other stuff, and in most cases you find the solution sooner of later.
By chance, I was working on another iCloud issue, when I noticed I had switched iCloud accounts. Meaning, that when I’m developing in xCode, I connect with my developer account to iCloud (and CloudKit), and my iMac was using my personal iCloud account… of course this doesn’t work. Accounts are synchronized, not devices, so when you are not logged in to the correct account, you don’t get any updates. OMG, how stupid.

That being said, I do find Apple should allow me to have more than one iCloud account active. Maybe you have a personal and business iCloud account, and you want the corresponding apps to sync, or even get the info of the two account both displayed in the app.
You could share items with other accounts, but this doesn’t really cover it for me.

Anyway, I learned a lot, but basically lost a lot of time trying to solve a problem that didn’t exist.
Have a nice week…

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!

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.