June 29, 2021

Independent watchOS Apps

Speaking of watchOS apps, it looks like developing a full fledged application running entirely on watchOS is not yet possible: there is no networking to speak of on watchOS. 😔

If you need anything beyond basic HTTP or CloudKit, the only option is to use WatchConnectivity framework to funnel all networking through the extension running on the iPhone. 😢

The only hope is that it will be added in the future.

Posted by Vadim at 6:40 PM | Comments (0) | TrackBack (0)

June 13, 2021

Finishing Failed Transactions

On the topic of regressions in minor iOS updates, there was another one a bit ago on iOS 13.4 release, as I recall. That one was in the StoreKit API, and it has changed the way how failed transactions are being processed.

Normally, you have to finish every transaction passed into your SKPaymentQueue delegate once you are done processing it, and that includes failed transactions. However that wasn't the case on iOS 13.3 and earlier releases: failed transactions did not require finishTransaction: call and were removed from the queue even if they were not acknowledged.

Starting with iOS 13.4 though, you have to acknowledge all transactions.

[[SKPaymentQueue defaultQueue] finishTransaction: transaction];

Posted by Vadim at 11:31 AM | Comments (0) | TrackBack (0)

May 4, 2021

OpenSSL on Apple Watch

I needed OpenSSL library for the project I've been meaning to start for Apple Watch. So I've checked in all the usual places, and found out that one wasn't made available yet, so I thought I'd take that on myself.

That meant compiling it for watchOS platform, and four different architectures: armv7k and arm64_32 for device, and x86_64 and arm64 for the Simulator. That last one is a new addition in Xcode 12 to support new M1 Macs. I don't have one yet, but it would help to prepare for the future.

And that presents first problem. Earlier, before M1 arrived, it was possible to combine a library built for, say, iOS platform on arm64 architecture with library built for iOS Simulator on x86_64 into single Mach-O universal binary (or "fat library"), and Xcode was able to figure out which one goes where, even though universal binary does not identify platforms for each included architecture. Now with both M1 and iOS devices running on arm64 architecture, we have two platforms with the same architecture, and it is not possible to create such universal binary at all.

So the solution is to create separate "fat libraries" for each individual platform. That means separate library for:

  • iOS,
  • iOS Simulator,
  • tvOS,
  • tvOS Simulator,
  • watchOS,
  • watchOS Simulator,
  • ... and Catalyst, of course.

This presents second problem. Previously, you'd just drop single libcrypto.a (and libssl.a, if needed) into your project, and call it a day, but now you have to figure out how to make Xcode use one file, libcrypto-iOS.a, on device, and another, libcrypto-iOS-Sim.a, on Simulator.

Solution to the second problem is new XCFramework framework format. It combines libraries for all of these platforms (and corresponding header files) into single directory, and then Xcode magically picks just the right library automatically. 🎩 It can be easily created using xcodebuild by passing it a few parameters.

Resulting script is available on GitHub, and there is also a pull request against parent repository. And below is requisite screen shot of OpenSSL library running on watchOS as a proof that it works:

WatchOS-OpenSSL.png

Posted by Vadim at 6:59 PM | Comments (0) | TrackBack (0)

April 27, 2021

Regressions on Minor iOS Updates

We've gotten used to getting new iOS version every year, and to a requisite regression cycle to make sure new iOS version has not broken anything inside the apps. In recent years though, there have been significant changes in SDK even between minor releases, and I'm not talking about feature additions, but regressions in core libraries, such as UIKit.

As one example of such regression, update from iOS 13.1 to iOS 13.2 introduced breaking change to UIAlertController. Before, it worked just fine when presented as an action sheet on iPad in compact environment on iOS 13.1 or earlier:

UIAlerController-ActionSheet-iPad.png

With iOS 13.2 and later, this is no longer the case, and running the same code results in runtime exception:

*** Terminating app due to uncaught exception 'NSGenericException', reason: 'Your application has presented a UIAlertController (<UIAlertController: 0x7f9cc9056a00>) of style UIAlertControllerStyleActionSheet from UINavigationController (<UINavigationController: 0x7f9cca030600>). The modalPresentationStyle of a UIAlertController with this style is UIModalPresentationPopover. You must provide location information for this popover through the alert controller's popoverPresentationController. You must provide either a sourceView and sourceRect or a barButtonItem. If this information is not known when you present the alert controller, you may provide it in the UIPopoverPresentationControllerDelegate method -prepareForPopoverPresentation.'

Oh well... 😞

Posted by Vadim at 7:13 PM | Comments (0) | TrackBack (0)

January 26, 2020

Emojis on MovableType! 😎

Emojis are so ubiquitous today that it's hard to believe that they have been adopted by Unicode and started appearing in wide use only about 10 years ago. And I have gotten used to them as well and wasn't expecting at all when in the blog post draft instead of, say, 🧟‍♂️  I saw only four question marks. ????. That meant my MT5 install did not support emojis. I had some more fixin' to do. 😞

In particular:

  • I'd require a Perl version which supports Unicode, and preferably recent version, with up to date Unicode support. Fortunately, I have updated to Perl 5.26, and it supports Unicode 9.0. 🎉
  • MySQL database should be configured to use UTF-8... And that's where trouble starts, since apparently `utf8` does not mean what you think it means, and you have to use `utf8mb4` character set (and `utf8mb4_unicode_ci` collation) to make emojis specifically and newer Unicode in general work. 😒 Easiest way to change character encoding and collaction for the whole mt database for me was export, edit SQL file, and re-import process. It was also a good opportunity to do other updates, such as switch from MyISAM to InnoDB engine. ✨
  • Lastly, it seemed that MT4 itself was already supporting Unicode. Looks like that support was not 100% correct, but I was hoping it should be enough for my needs... Not quite, there was one more step: MT's database connection had to be now configured to use `utf8mb4` instead of `utf8`, and I've added `SQLSetNames 1` line to the `mt-config.cgi` file for the good measure.
  • While making all these changes, I've also noticed that MT4 setup might be in need of some hardening, and disabled some extra scripts.

Result? Complete success! 🚀

Posted by Vadim at 2:05 PM | Comments (0) | TrackBack (0)

January 12, 2020

Updating MovableType

Picking up where I've left off. While MT5 runs on Perl 5.20 well enough, it wouldn't be a good idea to stay on unsupported version for long, so for the next step, I've though to update to the currently installed version, Perl 5.26. After a bit of trial and error, it was much easier than I thought, it had required only a couple of changes to the CMS.pm file, and an update to the URI::Escape.

For the good measure, I've updated Data::ObjectDriver module, and put all that up on GitHub, in case someone else is looking to make his MovableType install run on current environment.

Posted by Vadim at 5:40 PM | Comments (0) | TrackBack (0)