Forem: Eldar E.

Embedding Python interpreter inside a MacOS app (and iOS app), and publish to the App Store successfully.

Eldar E. — Sat, 03 Dec 2022 13:20:37 +0000

The struggle was real

When I started looking into this topic, I quickly realized most of the guides, tutorials and StackOverflow answers have only partial information or straight out give bad advice, that would prevent you from publishing your app on the Apple's App Store.

I had to scramble though all that and was finally able to embed a Python interpreter in a MacOS app, fully signed and with the ability to be published to the App Store.

So here it is, a quick and simple guide on how-to embed a Python interpreter into your app. It's really simple when you have clear steps.

Why would we even need this?

As a native Apple eco system developer (I mostly do iOS these days), I believe Swift is the only way to go when developing for iOS and MacOS.
But, there are times your app requires something big you don't want to reinvent, and it's only available in Python. Then why not use it?

Python has so many tools and Open Source code you can use straight out of the box, that can empower your application with amazing functionality, and you can easily call Python code from Swift.

But be careful, by embedding a Python interpreter in your binary, you enlarge it by around ~100MB. So I wouldn't recommend this for simple stuff you can either do yourself in Swift or find a well maintained SPM.

Can you publish these kind of MacOS apps on the App Store?

Yes. You can embed Python and publish to the MacOS App Store.

While MacOS already comes with Python, you don't want to use it.

You can't rely on the Python version installed on the system.
This will require you to delete your MacOS app's Sandbox and Disable Library Validation. And once you do it, you can't submit your app to the App Store, and you even might have issues with the Notarization outside the App Store: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

On the other hand, by embedding the Python interpreter you allow the Python part of your app to be signed as well.
This allows the Hardened Runtime to remain intact:

NO NEED to delete the Sandbox - you need it to be able to submit your MacOS App to the App Store.
NO NEED to Disable Library Validation.

What about iOS?

Yes. You can embed Python and publish to the iOS App Store. Just look at Pyto: https://pyto.app
There is no limitation from iOS App Store on doing so. It's all signed as a single app.
The process of embedding Python on iOS is very similar to MacOS, but it might require a few more steps I will cover in a future article.

Step-by-step to embed Python interpreter in a MacOS app

Add PythonKit SPM:
https://github.com/pvieito/PythonKit.
Download Released framework for the desired Python version (for MacOS platform):
https://github.com/beeware/Python-Apple-support
Extract the python-stdlib and Python.xcframework from the tag.gz archive.
Copy them to the root of the MacOS App, preferably via Xcode.
Xcode General -> Frameworks:
5.1. Should already be there:
- Python.xcframework is set as Do Not Embed
- PythonKit
5.2. Add additional required framework:
- SystemConfiguration.framework set as Do Not Embed
Xcode Build Phases:
6.1. Verify Copy Bundle Resources contains python-stdlib.
6.2. Add bash script to Sign .so binaries in python-stdlib/lib-dynload/:
IMPORTANT NOTE: .so binaries must be signed with your TeamID, if you need to use Sign and Run Locally it will be signed as ad-hoc, and you will need to Disable Library Validation.

set -e
echo "Signing as $EXPANDED_CODE_SIGN_IDENTITY_NAME ($EXPANDED_CODE_SIGN_IDENTITY)"
find "$CODESIGNING_FOLDER_PATH/Contents/Resources/python-stdlib/lib-dynload" -name "*.so" -exec /usr/bin/codesign --force --sign "$EXPANDED_CODE_SIGN_IDENTITY" -o runtime --timestamp=none --preserve-metadata=identifier,entitlements,flags --generate-entitlement-der {} \;

Create a file called module.modulemap with the following code:

module Python {
    umbrella header "Python.h"
    export *
    link "Python"
}

Place the module.modulemap file inside the Python.xcframework/macos-arm64_x86_64/Headers/.
This will allow us to do import Python
Init Python at runtime, as early as possible:

import Python

guard let stdLibPath = Bundle.main.path(forResource: "python-stdlib", ofType: nil) else { return }
guard let libDynloadPath = Bundle.main.path(forResource: "python-stdlib/lib-dynload", ofType: nil) else { return }
setenv("PYTHONHOME", stdLibPath, 1)
setenv("PYTHONPATH", "\(stdLibPath):\(libDynloadPath)", 1)
Py_Initialize()
// we now have a Python interpreter ready to be used

Run test code:

import PythonKit

let sys = Python.import("sys")
print("Python Version: \(sys.version_info.major).\(sys.version_info.minor)")
print("Python Encoding: \(sys.getdefaultencoding().upper())")
print("Python Path: \(sys.path)")

_ = Python.import("math") // verifies `lib-dynload` is found and signed successfully

We're in business. Now we can add whatever python code we want. To integrate 3rd party python code and dependencies, you will need to make sure PYTHONPATH contains their paths; And then you can just do Python.import(" <SOME LIB> "). Sometimes, the python code might be too complicated to call with PythonKit from Swift, so my recommendation is to write a small Python script and call that script's method from Swift instead.

Good luck.

^(;,;)^

UPDATE:
I've submitted the above steps to be the official usage guide for BeeWare's Python-Apple-support. If you're having trouble with the above steps, the usage guide might contain additional info: https://github.com/beeware/Python-Apple-support/blob/main/USAGE.md.

Forcing iOS localization at runtime -the right way.

Eldar E. — Mon, 21 Oct 2019 13:04:08 +0000

iOS localization, and how it should be done

From Apple internalization docs:
Localization is the process of translating your app into multiple languages.

Sounds simple enough, and most of the time it is. You add resources for the languages you wish to support and iOS will automatically select and use one according to user’s device language.

But what if your app specification requires you to force a specific language at runtime? Here is where things get a bit tricky.

In this short article, I’m going to talk about forcing localization, and the right way to approach this topic.

So, you need to force a language?

Here are some of the reasons you might need to force a specific language:

Allow users to pick a language, and switch it on the fly.
The app is designated for a specific country but must be displayed in a different language.
The same app needs to be released to different countries and used only with their native tongue.

At Healthy.io I had a requirement similar to #3, same app with multiple languages. Usually, the simplest way to achieve this is to set a different target for each variation of the app and compile only with the Base language resources.

But, there’s a catch. You need to manage multiple targets and their settings, like Build Phases, Build Rules, etc.
Every change you make to one target’s settings will need to be duplicated to other targets.

An alternative is to keep a single target, with multiple schemes and set the language at runtime.

Pros:

Single target, easy to maintain.
Extremely easy to add a new app variations with new languages.

Cons:

Depends on your localization resources, it might be bloated since your binary was compiled with all the languages.
Apple doesn’t really like this approach, but it shouldn’t cause a rejection during the review.

Forcing a language at runtime

**Here is what Apple has to say on the matter: **
In general, you should not change the iOS system language (via use of the AppleLanguages pref key) from within your application.
This goes against the basic iOS user model for switching languages in the Settings app, and also uses a preference key that is not documented,
meaning that at some point in the future, the key name could change, which would break your application.

After a short research you’ve definitely seen this:

While it does work, it’s not a complete solution for one simple reason:
It requires an app restart. Meaning, the user starts the app for the first time, sees a wrong language, closes the app and starts it again. Great user experience! 😏

What should you do?

The above line of code is the right direction, but by itself, it’s not enough to provide a good user experience.

**From Apple: **
If you want to switch languages in your application, you can do so via manually loading resource files in your bundle.
You can use NSBundle:pathForResource:ofType:inDirectory:forLocalization: for this purpose, but keep in mind that your application would be responsible for all loading of localized data.

In order to achieve the right language on the first app start, you need to access the desired language bundle yourself:

Great! But we don’t want to deal with this part everywhere: “keep in mind that your application would be responsible for all loading of localized data”.
To make it work seamlessly we’ll need to swizzle localizedString(forKey:value:table:) to access the desired bundle.

In case you’re not familiar with swizzling, you should read Method swizzling in iOS swift.

From the article:
Method swizzling is the process of changing the implementation of an existing selector at runtime. Simply speaking, we can change the functionality of a method at runtime.

(Please note, that while I'm against swizzling in general, I think cases like these are a good example of when it's ok to swizzle.)

The complete code:

And one last thing; To ensure RTL/LTR switch, you need to reload the rootViewController.

Don’t reinvent the wheel

That's it? Not quite. If you need Storyboard/Nibs support or just don't want to manage this yourself, then I have good news for you! There's a great library called LanguageManager-iOS.
It’s small, easy to use, maintained, and supports Carthage, Cocoa-Pods and SPM. Jackpot!!

Quick usage example on how to set the default language on app start with LanguageManager-iOS:

IMPORTANT UPDATE: LanguageManager-iOS No longer supports swizzling

The LanguageManager-iOS lib v1.1.4+, no longer swizzles, thus requires you to call String.localiz() yourself. You can find more information in the Github issue: https://github.com/Abedalkareem/LanguageManager-iOS/issues/46

textAligntment = .natural

textAlignment = .natural can’t be trusted on first app start, and needs to be handled manually for UITextView, UILabel, and UITextField.

**Important Note: **Just to be on the safe side, you should set the text before textAligntment is set.

Localized Info.plist

Sadly, Localized Info.plist ignores runtime language set, and so far I was not able to resolve this issue.

Final thoughts

When you need to stray from Apple’s path, localization becomes a hassle; So I’m really glad someone took the time to make and maintain a lib like LanguageManager-iOS.

If you have notes, additional issues/solutions, please don’t keep them to yourself.

Cheers! 🎈

Eldar.

Calling your other iOS app with parameters, even if it’s not yet installed; Without a website, or 3rd party services.

Eldar E. — Mon, 21 Oct 2019 12:55:34 +0000

Consider the following scenario:

You have 2 apps, A and B. App A needs to launch App B with a username, and maybe some other more complex data structure. And we can’t assume App B is even installed.

There are various ways to do this.

Possible solution #1: A simple Deep-Linking with parameters should do the trick; And for when App B is not yet installed, we can use a 3rd party service like Branch. But, can you really trust them to connect the dots and be able to communicate the data reliably after the user installs App B?

Due to the hacky nature of such 3rd party services, while they work most of the time, occasionally they do fail to pass the data to the target app.

Also, don’t forget that Apple is all about privacy these days, and services like Branch are no different than tracking tools.
Speaking of privacy, the data you want to send to App B might be sensitive, so you need to trust Branch with your users’ data.

Possible solution #2: Universal Linking, is Apple’s alternative to Deep-Linking, and it does allow you to pass parameters to App B, even if it’s not yet installed. But, then you need a website and network availability. It might not be for everyone.

If only App A could communicate complex (preferably Codable) data to App B, without all the hassle and disadvantages of the above orthodox solutions.

Introducing App Groups

App Groups was designed to share data between the main app and it’s extensions, but it can also be used to share data between two apps under the same publisher.
From the code perspective, App Groups is basically a UserDefaults in a shared container.

A quick example

Here is what needs to be done to communicate a username string, from App A (sender) to App B (receiver), even if App B is not yet installed.

I. Create App Groups, on both apps:

For both App A & App B, go to Capabilities, enable App Groups, and create a group. For this example let’s call it “group.myAmazingApp”.

Note: according to Apple, it must be group..

II. Create URL Scheme for app B:

In order to allow app A to open App B, we need to setup the URL Scheme in App B. In App B, go to Info.plist -> URL Types, and create new; For this example we’ll call it “appB”.

III. Allow App A to access App B’s URL Scheme:

Explicitly whitelist App B’s URL Scheme, to allow App A to call it.
In App A, go to Info.plist -> Custom iOS Target Properties, create LSApplicationQueriesSchemes as an Array, and add “appB”.

IV. Code for App A (sender):

V. Code for App B (receiver):

Summary

App Groups is an interesting alternative to communicate data between your apps, with plenty of pros, and some cons.

Pros:

Simple setup and use.
Allows to start an app with one or more parameters, even if the target app is not yet installed.
No need to own a website for your app, or even access to network.
Unlike with Universal-Link and Deep-Linking, data can be complex with Codables via Data.
Pretty secure/private, as any data on a user’s device; Everything is stored locally, and can only be accessed by the same publisher.

Cons:

It might be more secure than Deep-Linking, but it’s no more secure than your app’s container UserDefaults; So you shouldn’t use it for sensitive data.

Your opinion matters

Should this method be turned into a dual communication channel for same publisher’s app to transfer data locally? Let’s discuss in the comments.

Cheers! 🎈

Eldar