One of the reasons why artificial intelligence (AI) failed during the early days was because it required humans to program intelligence into a program. That meant exhaustively writing instructions for every possible outcome.
One of the earliest and more limited successes of AI were expert systems that consisted of a series of if-then rules to mimic the thinking process of a human expert. The reason why expert systems worked was because they could tackle a narrow niche with limited and known variables. The reason why expert systems ultimately failed is because they couldn’t advance beyond narrow niches and required humans to exhaustively write if-then rules for every possibility.
Even worse, when conditions changed, human programmers had to go back into the expert system to reprogram it and update it. This constantly meant consulting with a human expert and a human programmer, which made the expert system cumbersome to modify to the point where it wasn’t worth it at all.
That’s all changed with machine learning. The whole idea behind machine learning is to let a program teach and update itself. Not only is this far faster, but it’s far more accurate allowing the program to adapt to changing conditions. If you’re interested in machine learning with Swift, download the open source, Swift AI library.
This Swift AI library lets you create neural networks for both macOS and iOS. By incorporating machine learning in your apps, you can create more adaptive video games or smarter programs that can recognize handwriting or user behavior.
Trying to create machine learning tools on your own in Swift is possible, but clumsy. It’s so much easier to use a tested machine learning framework instead, so that’s why you might want to experiment with Swift AI.
As Swift gains popularity, it’s likely that others will create machine learning frameworks for Swift but until that day comes when we can choose from a variety of machine learning tools, Swift AI offers the best way to experiment with machine learning using Swift.
At the very least, dig through the sample programs in the Swift AI library and give yourself a rudimentary understanding of how machine learning works and how to implement it in Swift.
To download the Swift AI library for adding machine learning to iOS and macOS programs, click here.
Posted in Algorithms, iOS, macOS
In any programming language, you can choose arbitrary names for your functions and parameters. For example, you could create a completely valid but confusing function like this:
Notice that the function name (x239) and parameter name (jke) provides no clue what they do. Although this code is perfectly valid, it’s confusing so it’s always best to choose descriptive function names and parameter names such as:
This function name (printGreeting) and parameter name (name) is much clearer as to the functions purpose, which is to take a name and print a greeting. Of course, this function could actually calculate a differential equation so it’s generally best to choose descriptive function and parameter names that actually describe the purpose of the function.
To call this function, you could use code like this:
The function call uses the printGreeting name and identifies the name (“Sam”). This is perfectly fine but in Swift, you have the option to use external parameter names. This means you can have two parameter names, an external and an internal parameter name.
The internal parameter name is what the function actually uses while the external parameter name is what you use to call the function. So to make the function call read more like an actual sentence, you could use an external parameter name like this:
Notice that the function uses “name” as a variable for the actual code, but when you’re calling the function, you use the external parameter name like this:
Now the function call reads like a complete sentence such as “Print greeting for Sam.”
You may not want to do this for your own function declarations and calls, but you’ll find that many Swift API calls use external parameter names specifically to make function calls seem more like a sentence, typically using external parameter names of “in,”, “for”, and “with”.
External parameter names simply help make code more readable although at the expense of also making function declarations more cumbersome to write. You can choose to use external parameter names or not, but whether you use them or ignore them, you’ll at least better understand why so many of Apple’s API functions look the way they do using external parameter names.
Posted in Algorithms, iOS, macOS
Many people want to create an iOS app. While there are many companies and programs that promise to make this task easy, they all have tradeoffs. Either they cost a lot of money or they’re too limited to create any but the simplest apps.
The free solution is to learn Xcode, which is Apple’s free editor/compiler. Unfortunately, learning Xcode isn’t as straightforward as you might think.
First, you have to learn a programming language. Xcode supports Apple’s two official programming languages, Objective-C and Swift. Of these two choices, learn Swift and ignore Objective-C if you can. Objective-C is far more confusing, convoluted, and complicated than Swift. In fact, Apple created Swift specifically to fix all the problems of Objective-C while still being equal or even better than Objective-C.
So if you ant to create iOS apps, you must first learn the Swift programming language. This by itself isn’t that difficult because Xcode offers a feature called playgrounds that lets you practice writing Swift code without the hassle of writing complete programs. With Swift playgrounds, you can test your ideas out quickly and easily, so Swift is the best programming language to learn and use for iOS development.
Once you learn Swift, you have a second task in learning how to use Xcode. Xcode contains multiple commands for professionals, which means novices will often feel intimidated by the program. Fortunately you can sue Xcode without knowing or using all of its features. However, this means you must learn both Swift and Xcode.
Now to make matters more confusing, you not only need to learn Swift and Xcode, but you also need to learn Apple’s Cocoa Touch framework that provides commonly used code to create iOS apps.
So if you want to learn iOS programming, you have to learn Swift, Xcode, and the Cocoa Touch framework. That’s three different topics you must master before you can even start writing an iOS app.
If you have a burning idea for an app, the first step is never to start writing a program, but to figure out if your idea is any good in the first place.
First, ask what problem your app will solve. Next, ask other people if they might find your app useful. Finally, ask yourself why you want to create an app in the first place. If your only goal is to make money, chances are good you won’t make money because obstacles will appear and frustrate you long before you can complete your app and start making money. Unless you actually enjoy programming, don’t think creating an app will suddenly make you rich.
In fact, most app developers don’t make money. There are so many apps in the App Store that new apps get lost in the crowd everyday. That makes it hard for potential customers to find your app and even if they do find it, they’ll be far less likely to pay for an unknown app. That means you must find ways to convince people to try and eventually buy your app.
In other words, that requires taking time to learn how to market your app. If you thought learning Swift, Xcode, and the Cocoa Touch framework were enough, now learning marketing is a fourth task you must master as well. Without marketing, your app won’t attract many sales and you won’t make a lot of money (if any).
It’s still possible to make money selling apps, but it’s not easy, simple, or fast for anyone to do so. If you’re creating an app, be prepared to market and support it for years. In other words, create an app because it will solve your own problem or because it’s fun. Don’t try creating an app just to get rich because chances are good you won’t.
Creating an app isn’t difficult but is tedious and time-consuming. Unless you’re willing to put in the time to learn, then spend your time more productively doing something you really enjoy. If you really enjoy programing, then start learning Swift, Xcode, the Cocoa Touch framework, and marketing.
Who knows? You might wound up having fun and making money, but that’s only if you enjoy learning and mastering all these tasks simultaneously.
Creating an app isn’t any harder than mastering any skill such as learning to rebuild a car engine or knitting a quilt. It just takes time and desire. If you don’t have the desire, you won’t make the time. If you do have the desire, you will make the time and then you’ll find the world of app creation can be far more rewarding than just the financial rewards alone.
Posted in iOS, Xcode
If you look at the apps that come with an iPhone or iPad, you’ll notice that one common feature is the use of rows of data such as viewing a list of email messages in the Mail app. Whenever you see multiple rows of data that you can scroll up or down on the screen, chances are good it’s a table view.
The basic idea behind a table view is to create a dynamic list of information on the screen that users can scroll through and tap to select. The first step is to put a table view (not a table view controller) on a view (the user interface).
Once you have a table view on your user interface, the next step is to write the actual code to store data in that table view. First, you must make sure your class adds the UITableViewDelegate and UITableViewDataSource as follows:
Second, you need to define your data. The simplest example is to use an array such as:
To physically access and display data in a table view, you need to create an IBOutlet between the table view on the user interface and your actual Swift class file like this:
Fourth, you need to define which file will act as the table view’s delegate and data source. If you store everything in a class file, you can just make the class file the delegate and data source. One way to do this is by control-dragging from the table view on the user interface to the view controller icon. However a more visible way to do this is to define this in Swift code like this:
Now you need to define how many items will appear in the table view. Since this number can vary, you need code that will automatically count the number of items to display. If you’re storing data in an array, you can use the array count method to define the total number of items to display in a table view like this:
Finally, you need to give the cell, in your table view, a unique identifier name such as “myCell” so you can identify it. Then the final step is to use this cell to fill with data. The first line of the following function tells the table view to use the cell identified by its name.
The second line says to store an array element into the text property of the cell.
The third line says to show that data in the cell of the table view, so the whole function looks like this:
If you want to identify which table row the user tapped on, you need to write another function like this:
So if you put a table view on your user interface and name the cell in that table view as “myCell”, the whole code looks like this:
Posted in iOS, Xcode
if you’ve ever used the appointment feature of the iOS calendar, you’ve seen a spinning dial that lets you choose among multiple options such as the names of different months and days. A PickerView simply displays options that the user can choose. To fill a PickerView with data, you can use an array and place that PickerView on the user interface.
Next, you have to add the UIPickerViewDelegate and UIPickerViewDataSource to the class linked to the view (user interface) like this:
Then you have to get data to place in the PickerView, which can be an array like this:
You also need to create an IBOutlet for your PickerView so you can refer to it in Swift code like this:
Once you’ve created an IBOutlet for your PickerView, you can then set its delegate to the view controller Swift file like this:
Now you need to define the number of parts or components in your PickerView. The simplest PickerView displays just one type of data so you can define just 1 using the numberOfComponentsInPickerView function:
You must also define how many items to display in the PickerView. If your data is an array, you can just count the number of items in the array using the pickerView function:
Finally, you need to actually fill the PickerView with your data using another pickerView function:
Your entire ViewController.swift file can look like this when linked to a view (user interface) that contains a picker view control:
Posted in iOS, User Interface
if you’re creating an iOS app that requires typing text, your app will need to display the iOS virtual keyboard that slides up from the bottom of the screen. The problem with the virtual keyboard is that although it pops up automatically, you have to write code to make it go away.
There are basically four steps you need to follow to write code that makes the virtual keyboard go away. First, you’ll likely need a text field to allow the user to type text on the virtual keyboard, so you need to add the UITextFieldDelete to your class file like this in Swift:
Second, you’ll need to set the text field to the UITextFieldDelegate. You can do through the Connections Inspector on Xcode or just use code like this in Swift:
Third, you need to create a function called textFieldShouldReturn to end editing. This function hides the virtual keyboard if the user taps the Return key:
Fourth, you need to create a second function called touchesBegan to tell the text field to let the virtual keyboard disappear if the user taps anywhere away from the text field:
So if you create a simple iOS, single view app in Xcode using Swift, just place a text field on the view (user interface) and link it to your view controller file as an IBOutlet such as naming the text field “textFieldEntry”. Then your entire Swift class would look like this:
Now if the user taps the Return key on the virtual keyboard or taps away from the text field and the virtual keyboard, the virtual keyboard will tuck itself out of sight.
Posted in iOS, Programming, Xcode
If you’re involved in programming, you know how important it can be to learn the right programming languages. Every programmer should learn the basics of C along with object-oriented programming because those two topics can help you learn Java, Objective-C, and C#. If instead of learning C and object-oriented programming, you decided to focus solely on FORTH and Modula-2, would you think you would have as many opportunities available to you as another programmer versed in C and object-oriented programming?
If you want to learn the most important new programming language in recent years, you absolutely must learn Swift. Not only is Swift used to create iOS (iPhone and iPad) apps, but it can be used to create watchOS app for the Apple Watch and tvOS for Apple TV. That’s four major platforms you can support with Swift.
Stick with C# and you’re basically stuck in the stagnant world of PCs. Stick with Java and you can do web programming along with Android programming. Whether you learn C# or Java is far less important than learning Swift because Swift is now moving to Linux and other platforms such as Linux servers.
To help programmers learn Swift, IBM has created a site called the IBM Swift Sandbox, which lets you practice running Swift in a browser. Right now the only way to learn Swift is by using Xcode on a Macintosh. For anyone who doesn’t have a Macintosh, get one and start learning to use Xcode and Swift.
If you can’t afford a Macintosh right now, use IBM’s Swift Sandbox to learn Swift on your browser. This can be especially useful for iPad users. Since you can’t write programs using an iPad, you can use IBM’s Swift Sandbox to learn Swift on your iPad’s browser. Now you can learn Swift on any device you want as long as it has a browser.
Knowledge of Swift is crucial for any programmer’s future so the sooner you start learning, the better off you’ll be. As long as the iPhone, iPad, Macintosh, Apple Watch, and Apple TV continue making profits and grabbing market share, they’ll always be a demand for Swift programmers.
Now that Swift will migrate to servers along with platforms like Linux and eventually Windows, Swift could be the universal programming language like C that every programmer must learn.
Start learning Swift today. Your future as a programmer literally depends on it.
Posted in iOS, Programming, Xcode
Just as Apple had promised earlier this year, the Swift programming language is now open source. The reason for making Swift open source is to speed up Swift’s adoption on servers and on other platforms such as Linux and Windows in ways that Apple’s own programmers would never have the time to do on their own.
If you’re learning programming, Swift is going to be one of the most important programming languages to master. When Swift successfully ports to Linux and Windows, you should be able to write Swift programs for all major platforms.
Of course, you can already use Swift to write programs for all of Apple’s platforms that are either dominating their markets or steadily gathering market share. With Swift you can write programs for the following Apple platforms:
- OS X to create Macintosh programs for the steadily growing Macintosh market (while the PC market steadily declines)
- iOS to create iPhone and iPad apps for the dominant mobile computing market defined by the iPhone and iPad
- watchOS to create Apple Watch apps for the wearable computing market that the Apple Watch is helping define
- tvOS to create Apple TV apps for a new TV market that Apple is shaping
Right now with Swift you can support four major Apple platforms. With Swift going open source, you’ll soon be able to write server programs in Swift, running on Linux. You may eventually be able to write Windows programs and even Android apps in Swift as well. When that happens, you’ll be able to port your iOS programs to Android.
The future clearly belongs to Swift. If you’re learning any programming language, your school may have forced you to learn C++ and Java since both languages run on all major platforms and form the basis for other popular programming languages such as Objective-C.
However, you must learn Swift. Windows developers may focus on C# but C# has never migrated beyond Windows so it’s a dead end. With Windows PCs steadily declining, C# can’t help but decline at the same time.
On the other hand, Swift has a far brighter future ahead of it. If your school doesn’t teach Swift, learn Swift on your own. Swift will be the most important programming language of tomorrow (and even today) so if you don’t learn Swift, you might as well stick with archaic programming languages like FORTH and LISP and then wonder why you don’t have as many opportunities available to you.
To learn more about open source Swift, click here.
Posted in iOS, Programming
Back in the early days of the PC, VisiCalc dominated in the spreadsheet market. Two rivals soon appeared called Context MBA and Lotus 1-2-3. The biggest advantage of Context MBA was that it was written in UCSD-Pascal, which gave it cross-platform capabilities. That meant you could run Context MBA on MS-DOS or CP/M-80. Since nobody knew which operating system would dominate, this seemed like a smart bet.
On the other hand, Lotus 1-2-3 only ran on MS-DOS. That seemed like a huge limitation except that Lotus 1-2-3 was optimized for MS-DOS so it ran extremely quickly while Context MBA ran much slower on every operating system. As history shows, the world chose Lotus 1-2-3 and left Context MBA in the dustbin of history.
That’s the difference between coding for cross-platforms or coding for a single platform and optimizing your app to run on that one platform. Use a cross-platform tool like Xojo or LiveCode and you’ll get suboptimal performance on every operating system. Use Xcode and Swift to create iOS or OS X apps and you’ll get optimal performance along with the ability to take advantage of every feature offered by Apple’s frameworks.
What’s the drawback? With Xcode and Swift, you can’t make cross-platform programs that might run on Windows, Linux, or Android. That means you have to bet that iOS and OS X will be the platforms of growth just like Lotus 1-2-3 bet that MS-DOS would be the platform of growth.
In hindsight, Lotus 1-2-3 made the right choice. Today, it’s easy to see that iOS dominates the mobile market with the iPhone and iPad, and OS X is steadily growing as Macintosh sales steadily creep upwards while PC sales gradually decline.
Windows and Android represent huge markets, but iOS and OS X represent growing markets. Remember, at one time CP/M-80 was the dominant operating system and MS-DOS was the upstart. Obviously Lotus 1-2-3 bet on the upstart and won big, while Context MBA hedged their bets and lost all the way around.
The lesson of Context MBA and Lotus 1-2-3 is that native apps optimized for a specific operating system will give you greater performance. You just have to make sure your’e betting on the right platform.
Since iOS dominates the mobile market with the iPhone and iPad, it’s obvious that iOS will remain lucrative. Although Windows dominates the desktop computer market, it’s also easy to see that OS X growth is continuing, so there will be a steadily growing market for OS X programs.
Since mobile computing is growing rapidly and represents the future, it seems safe to say that iOS is the future. So decide what’s more important to you: cross-platform or native and optimized performance. Judging from the past of Context MBA and Lotus 1-2-3, it seems likely the answer will always be native, optimized apps.
To read a short history of Context MBA, click here.
Posted in iOS, LiveCode, Programming, Xcode, Xojo
In the past I avoided using Xcode and Objective-C any more than necessary because they were too complicated and cumbersome to use. In comparison, Xojo and LiveCode are two third-party development tools that are much easier to learn and use than Xcode.
Apple partly eliminated the problem of Objective-C by introducing a new programming language called Swift. Unlike Objective-C, Swift is much easier to learn and use while being easier to understand too.
The biggest drawback with Xcode is that it only lets you develop for Apple products. That’s what made Xojo and LiveCode so appealing. Besides being much easier to learn and use, both Xojo and LiveCode also let you create cross-platform programs that could run on Windows, OS X, and Linux. In addition, Xojo lets you create iOS apps while LiveCode lets you create Android and iOS apps.
I loved using Xojo and LiveCode, but with so much to learn and master, there just isn’t enough time to stay current with all of these tools. That’s why I’m saying good-bye to both Xojo and LiveCode.
Both tools are great at what they do. If you need a cross-platform program, Xojo and LiveCode are great. However, if you need to access all the features of OS X, iOS, watchOS, or tvOS, then Xojo and LiveCode can’t deliver.
Xojo is based on Microsoft’s Visual Basic 6 so if you’re a Visual Basic programming, you’ll have no trouble using Xojo. Even if you’re not a Visual Basic programmer, using Xojo is relatively easy.
LiveCode is based on Apple’s HyperCard. If you’re familiar with HyperCard programming, you’ll have no trouble using LiveCode. if you’re familiar with other programming languages like C or Java, LiveCode will look extremely wordy and verbose.
Chances are good traditional programmers will immediately dislike LiveCode while novices will love it because LiveCode works far more logically than traditional programming languages.
If you’re going to make a living as a software developer, you may still want to learn Xojo or LiveCode as a secondary programming tool, but not as your primary tool. That’s because neither tool is as well known or popular as Xcode for Apple programming or C# for Windows programming.
Learn C#, C++, Swift, or Java and you can find a job easily. Master Xojo or LiveCode and job opportunities are far fewer despite the fact that Xojo and LiveCode let you create programs faster.
Beyond the limitation of time, the biggest strike against Xojo and LiveCode is their inability to keep up with Apple’s latest frameworks. Xojo currently offers a subset of iOS programming that’s getting more robust and comprehensive everyday, but it will always lag far behind the capabilities of Xcode and Swift.
LiveCode also lets you access a subset of iOS programming, so despite being easier to use, you may run into limitations that neither Xojo nor LiveCode can handle on their own.
Xojo is $299 for the iOS compiler while LiveCode has raised their prices to $499 a year as a subscription. Unless you really can crank out programs for others to justify LiveCode’s steep annual subscription price, it’s a great tool that’s priced out of my range, let alone the price range of most other programmers as well.
Pricewise, LiveCode is the most expensive ($499 a year) but most flexible in creating cross-platform apps from Windows, Linux, OS X, Android, and iOS. Xoxo is next ($299) but can only create Windows, OS X, Linux, and iOS apps. Xcode is free but limited solely to Apple products (OS X, iOS, watchOS, and tvOS).
So if you have plenty of time on your hands, consider Xojo or LiveCode as great secondary tools for prototyping apps and creating quick and simple programs easily. If you’re like most people, you do’t have a lot of free time so you need to specialize. Windows programmers should focus on C# while Apple programmers should focus on Swift.
Don’t overlook Xojo and LiveCode, but don’t depend on them as your primary programming tool. If you do, chances are good you won’t have much company with fellow programmers or paying opportunities either. Xojo and LiveCode are great, but if you’re serious about developing for Apple products, Xcode and Swift is where you should be pouring all your attention.
For that reason, this blog will shift heavily towards Swift and Xcode with an occasional passing reference to Xojo and LiveCode. I love Xojo and LiveCode. It’s just that the best programming opportunities lay with Swift and Xcode instead.
Posted in iOS, LiveCode, Programming, Xcode, Xojo