Kind of missed the memo on this. “Kotlin/Native wi...
# kotlin-native
k
Kind of missed the memo on this. “Kotlin/Native will embed bitcode by default for iOS frameworks targets in Gradle projects.” Is that regular llvm bitcode, or the Apple-specific “bitcode” required for watch and some other builds?
I guess Apple specific? Just enabled and rebuilt on my test project and it seemed to work. Sweet!
s
Are you using master? The current release still has libffi bundled with it so it isn’t a pure bitcode project. Did you run it on an actual device or sim? Also I’m curious if it’ll pass inspection when you upload the binary to Apple. I know that when Apple released bitcode for ios in 2015 they were using a forked version that wasn’t compatible with the current (at the time) llvm. My Google Fu has failed several times when trying to find if they ever merged their fork back in. I think there’s also an llvm version difference between what is shipped with the latest Xcode (6.x) and Kotlin/Native (7.x ?)
k
Sim. If I get some time, or sell somebody on the team on it, can try device later. Also, can try to update droidcon app in the store. Related event won’t be till much later this year, so probably won’t impact anybody’s day
OK. Ran on actual device and it seems to work OK
Building archive. See how the upload goes, although I’m sure something is out of date with my Apple account
s
Are you building for a platform that is bitcode only (tvOS|watchOS)?
k
No
Running validate on ios app store now
message has been deleted
message has been deleted
Uploading now. Haven’t ever done a watch or tv app, but that would be an interesting test
s
Thinking about it some more, there would need to be platform support added for them in the compiler distribution. WatchOS and tvOS require different SDKs to link to.
The stuff going on in master with the libffi removal is definitely laying the groundwork for it to happen.
k
Not sure what’s up, but app has been uploaded and is now processing, apparently with bitcode enabled
I would’ve expected it to fail much earlier in the process if there were a problem
Processing takes FOREVER!!!
s
It might follow up with an email after it completes a deeper scan. I have a client that integrates a third party framework into their app that requires some lipo magic to strip out the non arm64 slices. It doesn’t remove the symbols for it and every time we upload a new version about 15-20 minutes later we get an email informing us about the extra symbols.
Yes, sadly it does.
k
Finished
message has been deleted
Listing doesn’t say anything about bitcode, though
s
The fact that you have the download dSYM link means it was built with bitcode. Apps without it don’t have that and the dSYMs need to be pulled from the machine that built it.
k
Well, guess it worked then!
Will push code to repo. Building with 1.3.20, so definitely not master
r
Why 1.3.20 and not 1.3.21? Having the fix for https://youtrack.jetbrains.com/issue/KT-28128 is nice when your actively developing on it.
k
Had some compatibility issue and life is short. Plan to get back to it at some point
s
As for now, we don’t embed real bitcode to a binary, we just mark the binary as if it was built from source code written in assembly language. It is definitely enough to make all the checks pass (since Apple still allows using assembler for iOS), but this trick wouldn’t work on tvOS and watchOS. We consider replacing this mark by real bitcode later, but this would indeed require some engineering and investigation work.
👍 4