Author: igo

File names are case sensitive in iOS. That’s why it is important always to test your app containing file read/write operations not only in simulator, but also on the real iOS devices like iPad or iPhone. In particular situations you get a file name from some configuration file and wonder why NSFileManage cannot find it in the folder where it is contained. This can happen when the name of the file in configuration has a different case than the real file name. Such a special case can be handled by the function below:

+ (NSString*)findCaseInsensitiveFileMappinhForFile:(NSString*)file inFolder:(NSString*)folderPath
{
    
    NSString *result = nil;    
    NSDirectoryEnumerator *enumerator = [[NSFileManager defaultManager] enumeratorAtURL:[NSURL fileURLWithPath:folderPath]
                                          includingPropertiesForKeys:@[NSURLNameKey, NSURLIsDirectoryKey]
                                                             options:NSDirectoryEnumerationSkipsHiddenFiles
                                                        errorHandler:^BOOL(NSURL *url, NSError *error) {
        if (error) {
            NSLog(@"[Error] %@ (%@)", error, url);
            return NO;
        }
        
        return YES;
    }];
    
    for (NSURL *fileURL in enumerator) {
        NSString *filename;
        [fileURL getResourceValue:&filename forKey:NSURLNameKey error:nil];
        NSNumber *isDirectory;
        [fileURL getResourceValue:&isDirectory forKey:NSURLIsDirectoryKey error:nil];
        
        // Find same file with different case
        if (![isDirectory boolValue]) {
            if ( [filename caseInsensitiveCompare:file] == NSOrderedSame) {               
                result = filename;
                break;
            }
        }
    }
    return result;
}

In most cases the WatchKit App you develop has to exchange data with its iOS App. In earlier versions of watchOS it was enough to define an app group to access the same data from the iOS app and from the WatchKit Extension. But since watchOS 3 things have changed. The apps for watchOS became native, i.e. they are natively executed at the Apple Watch. This implies of course changes in the way how the data is exchanged.

Watch Connectivity Framework is the way Apple provides to synchronize data with WatchOS Apps.

If your existing Watch app and iOS app use a shared group container or iCloud to exchange data, you must change the way you exchange that data in watchOS 2. Because the WatchKit extension now runs on Apple Watch, the extension must exchange data with the iOS app wirelessly. You can do that using an NSURLSession object or using the Watch Connectivity framework, which supports bidirectional communication between your iOS app and WatchKit extension.

To see a corresponding session click here: WWDC 2015 – Session 713 – watchOS

I could also recommend an excellent tutorial/overview for beginners: watchOS 2: How to communicate between devices using Watch Connectivity

Short summary of the most important things about Watch Connectivity Framework:

• Two separate stores have to be maintained. There is no automatic way for Core Data data to be synchronized with the watch app
• There are two communication categories: Background transfers and Interactive messaging
• Background transfers can be: Application context, User Info Transfer and File transfer. Application context is always overridden by the latest data when waiting in the transfer queue. User Info realizes FIFO principle, i.e. all data in the queue will be delivered. File transfer is self explaining.

Developing sophisticated apps is every time a challenge to find a proper way to provide scalability, testability, enable minimal maintenance cost. Without utilization of design patterns and suitable software architecture development process can get to a nightmare very quickly. Not only for the developer, but also for the customer. Of course, there is no general recommendation for utilization of this or that architecture pattern. It depends on particular requirements and expectations. The most popular architecture patterns are MVC, MVP, MVVM, VIPER etc. These patterns and their realization for iOS are discussed in a great article. Especially, advantages and disadvantages regarding testability and development overhead are discussed their. Comments are also worth reading!

iOS 10.3 seems to handle self signed certificates different then iOS 10.2. Even with the option NSAllowsArbitraryLoads enabled the request fails with the error:

The certificate for this server is invalid. You might be connecting to a server that is pretending to be “Domain name” which could put your confidential information at risk.

To fix the issue install the self signed certificate as usual. Afterwards go to

Settings -> About -> Certificate Trust Settings

and just enable the Full Trust for your root certificate.