Continuing my trend of writing about language processing, today I want to discuss about identifying the language of a body of text. This is an interesting task we can do thanks, once again, to Apple’s investment in APIs linked to machine learning.
Today we will explore the NLLanguageRecognizer object. Introduced in iOS 12, this class can do a lot of language recognizing, from detecting the “dominant language” of a string, to all the possible languages.
Working with Natural Language is possible thanks to machine learning. Starting on iOS 12, Apple has provided many APIs just for this task. In this article we will explore how to use NLTokenizer to separate natural language text into its proper units.
Introduction to Natural Language Tokenizing
If you are not familiar with the inner workings of Natural Language processing, tokenizing simply means that we separate a string and analyze it to find its semantic units. If you are writing a program that processes text, you may be tempted to split the string using a separator. For example, if you wanted to get all the words in a natural sentence string in an array, you would write something like this:
iOS has a lot of APIs that deal with natural language detection. One such class is NSDataDetector. This class allows you to match different kinds of data in text, including dates, time, links, and more. This class, actually introduced a very long time ago (in the iOS 4.0 days!) makes it very easy to find this kind of data in strings. In this article we will explore how to use this very old class - whose documentation is Objective-C only at this time - in Swift, and how to do common tasks with it.
As iOS becomes more advanced, features that we thought belonged to the long future start becoming more common place in today’s software. One such feature is speech recognition, which allows a device to take verbal input from a user, transcribe it into text, and do something with it.
In iOS, we can do this using a framework called Speech, and an object called SFSpeechRecognizer. With this class, you can perform all kinds of speech recognition tasks.
A few weeks ago, we talked about how we could play custom haptic feedbacks with CHHapticEngine. We saw how powerful and flexible that class is, letting us create different haptics for any context.
Sometimes though, you want to play simpler haptics to let the user know that something has occurred. The CHHapticEngine class can be overkill, and finding the right parameters to have interaction feedback can be very time consuming.
There is a subclass of UIFeedbackGenerator that actually exists since way before we got all the power CHHapticEngine: UINotificationFeedbackGenerator contains pre-made haptics to let users know when an action finished successfully, with an error, or a “warning” in the context of your app.
Apple’s CryptoKit introduced this year is full of amazing features. Not only does it offer very easy to use cryptography, but it also offers an interface to a security feature that Apple introduced less than a decade ago: The Secure Enclave.
The Secure Enclave is a hardware feature for helping the system work with cryptographically secure data. In this article, we will build upon our previous CryptoKit knowledge (see the article linked above), and we will also learn what the Secure Enclave is all about.
All the way back to 2016, a group of very talented iOS developers released Workflow, a very popular app to let users create actions of different kinds within the system’s constraints. You could create and automate different tasks, such as controlling a server via SSH, downloading all the images from a website, and more… Much, much more.
Apple saw the power of the app and acquired it in March 2017. This was very exciting, but we didn’t hear anything from the app since. Until WWDC 2018. Apple revealed a new app: Shortcuts. This app was built on top of Workflow, and as an Apple app, it allowed it to do many things that Workflow just wasn’t allowed to do, such as toggling system settings, integrating it with other apps (!!), and it was also natively integrated into Siri.
I just wanted to take a moment to wish you all a happy new year and to, to those who have been following me, for reading my weekly blog on iOS development since August.
As you may know, I originally started blogging in 2011 as a college freshman, mostly writing to document the new things I learned regarding iOS development. I had absolutely no consistency with how often I wrote. And in the timeframe the blog was alive (2011 - pre-August 2019), there were some pretty big gaps between articles - some spanning years.
In the article from last week, we explored the basic background execution APIs introduced since iOS 7. We explored how we could request additional time for a task to complete after entering the background, how we could defer downloads with URLSession, and how we could use silent push notifications to trigger background tasks.
The story with background tasks does not end there. iOS 13 introduced more APIs to do better background tasks, and that allow you to do things that weren’t possible before. Apple gave us the new shiny BackgroundTasks framework on WWDC2019. This framework gives developers more flexibility and less constraints to execute code while their apps are in the background. Not only that, but the old Background App Refresh APIs have now been deprecated in favor of a new, modern way to perform them for your app. This changes unifies with the new Background Processing tasks which lets you do more work in the background, while a device is charging, and more.
In the early days of iOS development, developers had no way at all to perform background tasks beyond a very limited constraints of tasks, like music playback. Modern demands go beyond allowing people to play music in your app while they use a different app, and we as developers need to adapt to these changes. VoIP, lengthy networking, and even silent pushes to keep an app updated are very common these days, and fulfilling these demands used to be hard, if not outright impossible.
