IOS Development

The Model-View-ViewModel, or MVVM pattern as it’s commonly known, is a UI design pattern. It’s a member of a larger family of patterns collectively known as MV*, these include  Model View Controller  (MVC),  Model View Presenter  (MVP) and a number of others. Each of these patterns is concerned with separating UI logic from business logic in order to make applications easier to develop and test. To understand the MVVM pattern better, it helps to look back at its origins. MVC was the first UI design pattern, and its origins track back to the  Smalltalk language of the 1970s . The image below illustrates the main components of the MVC pattern: This pattern separates the UI into the Model that represents the application state, the View, which in turn is composed of UI controls, and a Controller that handles user interactions and updates the model accordingly. One of the big problems with the MVC pattern is that it’s quite confusing. The concepts look good, but often when peo

How memory management is handled on iOS? Swift uses Automatic Reference Counting (ARC) which is conceptually the same thing as in Objective-C. ARC keeps track of  strong  references to instances of classes and increases or decreases their reference count accordingly when you assign or unassign instances of classes (reference types) to constants, properties, and variables. ARC does not increase or decrease reference count of  value types  because, when assigned, they are copied. By default, if you don't specify otherwise all the references will be strong references. One of the gotchas of ARC to be aware of is Strong Reference Cycles. Under ARC for a class instance to be fully deallocated it needs to be free of all the strong references to it. But there is a chance you could structure your code the way that two instances strongly reference each other and therefore never let each other's reference count drop down to zero. There are two ways of resolving this in Swift:  weak

An App ID is a two-part string used to identify one or more apps from a single development team. The string consists of a Team ID and a bundle ID search string, with a period (.) separating the two parts. The Team ID is supplied by Apple and is unique to a specific development team, while the bundle ID search string is supplied by teh developer to match either the bundle ID of a single app or a set of bundle IDs for a group of apps. Because most people think of the App ID as a string, they think it is interchangeable with Bundle ID. It appears this way because once the App ID is created in the Member Center, you only ever use the App ID Prefix which matches the Bundle ID of the Application Bundle. The bundle ID uniquely defines each App. It is specified in Xcode. A single Xcode project can have multiple Targets and therefore output multiple apps. A common use case for this is an app that has both lite/free and pro/full versions or is branded multiple ways.

I can’t believe it is over six years since I first wrote about  local notifications in iOS 4 . Well in iOS 10 Apple has deprecated  UILocalNotification  which means it is time to get familiar with a new notifications framework. Setup This is a long post so let’s start easy by importing the new notifications framework: // Swift import UserNotifications // Objective-C (with modules enabled) @ import UserNotifications; You manage notifications through a shared  UNUserNotificationCenter  object: // Swift let center = UNUserNotificationCenter .current() // Objective-C UNUserNotificationCenter *center = [ UNUserNotificationCenter currentNotificationCenter]; Authorization As with the older notifications framework you need to have the user’s permission for the types of notification your App will use. Make the request early in your App life cycle such as in  application:didFinishLaunchingWithOptions: . The first time your App requests authorization the system shows th