Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for visionOS. #31

Merged
merged 13 commits into from
Aug 20, 2023
Merged

Add support for visionOS. #31

merged 13 commits into from
Aug 20, 2023

Conversation

furby-tm
Copy link
Contributor

@furby-tm furby-tm commented Aug 18, 2023

This should roughly get visionOS most of the way there, albeit; quite a lazy approach I took here (using the same iOS simulator logic in many spots). There's probably a better way to do this in the long run.

Will need some additional double checking between the right usage of .visionOS vs .xrOS variants as I feel like I've officially confused myself now between the two! 😆

Note: there was some bashing between one of the dependencies and your fork of ArgumentParser, it appeared that a dependency was still looking for the Apple fork and not your fork -- as such, I simply took your fork and prefixed each of the library targets with ex: ArgumentParser <-> StackOtterArgParser to keep things split.

@stackotter
Copy link
Owner

Thanks for the PR, this is exciting! visionOS support is something that I've been thinking about since visionOS got announced, but I haven't even had time to play around with visionOS yet.

I haven't looked at your changes yet (I will in a sec), but just wondering, how much is working for visionOS so far? Do built apps successfully run in the simulator (or on-device if you're lucky enough to have one 😅)?

Also, if you don't me asking, what got you interested in Swift Bundler for visionOS, had you already been trying out Swift Bundler for other platforms?

Copy link
Owner

@stackotter stackotter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good so far! 🎉 Mostly just some comments about reducing code duplication, along with a few formatting suggestions.

I'll have to test out the functionality for myself before merging of course, so I'll try and get that done soon (and let you know how it goes).

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 18, 2023

@stackotter Hey! Thanks for looking into that PR. Yeah, I figured it’d need some work, I wasn’t 100% convinced it would work, so I just slapped things in there half hazardously, but it seems like it is basically exactly the same process as a iOS Simulator.

I’ll gladly polish up this PR in a few and anything else I can find.

As for the values, such as the reference to xros and things like that, I scoured the VisionOS SDK files gathering what I could to contextualize those values.

All works for me (at least to launch via swift bundler simulator — I have been suffering from some other issue regarding my OpenSSL certs, what is the command you run to spool up and code-sign/provision on run, I keep getting back that I’m self signed or something of that nature, and provisioning fails.

perhaps we need to allow OpenSSL to fallback to legacy mode?

@stackotter
Copy link
Owner

All works for me

Awesome, I'm downloading a newer Xcode version, and I hope to test out your changes today or tomorrow (I was still on beta 1 which didn't have visionOS support).

at least to launch via swift bundler simulator — I have been suffering from some other issue regarding my OpenSSL certs, what is the command you run to spool up and code-sign/provision on run, I keep getting back that I’m self signed or something of that nature, and provisioning fails.

That sounds like it probably affects iOS support too; open an issue for that with some details and I can look into it later.

As for the values, such as the reference to xros and things like that, I scoured the VisionOS SDK files gathering what I could to contextualize those values.

Yeah, it's a bit confusing lol, I think it's mostly correct. The only thing that seems wrong is xros-deploy (ios-deploy is a 3rd party tool not provided by Apple, and I can't seem to find anything called xros-deploy).

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 18, 2023

Nope that makes perfect sense! Yup I entirely guessed for that value, I wonder in that case if we should flip it to the same library? Not sure what that tool does as of yet, but if it’s agnostic enough to specific things around the simulator app it may just work for both.

edit: Nope, spoke too soon, it seems to be doing debugging on the bundle level, probably would need massive changes for that to work right.

@stackotter
Copy link
Owner

Nope that makes perfect sense! Yup I entirely guessed for that value, I wonder in that case if we should flip it to the same library? Not sure what that tool does as of yet, but if it’s agnostic enough to specific things around the simulator app it may just work for both.

The aim of ios-deploy is to install ios app bundles on physical devices. After a quick look at the ios-deploy code, it doesn't look too ios-specific. We can probably just modify ios-deploy (if it doesn't already work) to be more platform-agnostic. We'd probably need access to a physical visionOS device for testing.

Btw, ios-deploy is third party so it's open source and easy for us to modify.

@stackotter
Copy link
Owner

Looks like ios-deploy is just an objc cli which uses lldb to install apps on devices (with a python lldb script)

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 19, 2023

Also to answer your questions, I’m brand new to this bundler! It’s an exciting prospect, and I really appreciate all that you, as well as what so many other developers within the Swift community have been putting out. This stuff is experimental of course, but the quality and the sheer care put into this is incredible.

visionOS (my experience with it has just been as an emulator user myself) but has so far proven to be quite capable! I’ve had no issues building and running ex. RealmSwift on it, and whether you are building a “regular old 2D” app on it or an immersive experience - it has actually been mostly pretty streamlined, but I would say it is still far from perfect, but it appears to be about as analogous as building an iOS app for iPad as an example.

@furby-tm
Copy link
Contributor Author

@stackotter I noticed I hadn't added the change for the package-description-version passed to the swift build command, without 5.9 at a minimum you can't target visionOS.

I have made that required change here.

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 19, 2023

Also, this would be a fully separate issue - but commenting here to know your thoughts - there is a possibility that the ability to build for web (SwiftWasm) will eventually be supported by SPM natively, but until then, I think it would be great if this package could support targeting Wasm for complete cross-platform Swift app builds, using carton under the hood to build for that platform.

Additionally, SwiftCrossUI could default to TokamakUI when targeting SwiftWasm.

I have big plans for leveraging SwiftUI as the interface to translate to Pixar's Universal Scene Description under the hood, a fully cross-platform library for building, interacting, and introspecting 3D scenes, and would be a true cross-platform solution for creating augmented reality (AR) apps.

@stackotter
Copy link
Owner

@stackotter I noticed I hadn't added the change for the package-description-version passed to the swift build command, without 5.9 at a minimum you can't target visionOS.

Ah yep, good catch 👌

I think it would be great if this package could support targeting Wasm for complete cross-platform Swift app builds

Me too! I want Swift Bundler to support as many platforms as possible (but have only been implementing support for platforms I need because of time constraints)

I have big plans for leveraging SwiftUI as the interface to translate to Pixar's Universal Scene Description under the hood, a fully cross-platform library for building, interacting, and introspecting 3D scenes, and would be a true cross-platform solution for creating augmented reality (AR) apps.

That would be pretty awesome

Additionally, SwiftCrossUI could default to TokamakUI when targeting SwiftWasm.

Yeah that would work nicely. I've been planning to refactor things a bit to allow supporting multiple backends (in tokamak's case, it'd probably be more of a shim than a backend).

This stuff is experimental of course, but the quality and the sheer care put into this is incredible.

Thank you! 🙏 That means a lot

it appears to be about as analogous as building an iOS app for iPad as an example.

Sweet 👌 I'm glad that Apple has made it relatively seamless. I'll be interested to see how easy/hard it is to get Delta Client running in the visionOS simulator.

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 19, 2023

I'll be interested to see how easy/hard it is to get Delta Client running in the visionOS simulator.

It should work right out of the box! Though that Delta Client runs phenomenally well, the assumption there is it's written on Metal? I can't comment on how well Metal interoperability will work out of the box as I have not attempted anything on that end yet, I am hoping it "just works" on visionOS.

I also believe you should have all the changes now cleaned up per your review (of my rather sloppily & hastily made PR, sorry about that! 😛) Feel free to request I do any additional changes if need-be.

I have a funny feeling we will be working together here very soon! Cheers 🍷

Edit: whoops missed one 2e86b5f - think that should do it!

Copy link
Owner

@stackotter stackotter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, looks great! Thanks for implementing tools version parsing 👌 I've just left a single suggestion for the tools version parsing error message, but other than that I'm happy to merge once I've tested it out for myself (currently installing a newer xcode beta)

stackotter
stackotter previously approved these changes Aug 20, 2023
Copy link
Owner

@stackotter stackotter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome 👌 code looks good now, just trying to install visionOS support lol, it keeps erroring out

@stackotter
Copy link
Owner

I have found that I needed two changes to get visionOS support working. Line 29 of Platform.swift needs to return "xrsimulator" instead of "xrossimulator", and after line 103 of PlistCreator.swift you need to add entries["UIDeviceFamily"] = [7] for it to be successfully installed in the simulator. Other than that it seems to be working pretty great! Xcode project conversion will need some work to be able to support the structure of the default visionOS hello world project, but that feature is very experimental and doesn't work half of the time anyway so don't worry about that.

Again, awesome work! Can't wait to see whether I can get Delta Client running in visionOS

@stackotter
Copy link
Owner

Aw man, Delta Client relies on some packages which don't compile for visionOS yet. Looks like it might be a bit more work than I was hoping for.

@furby-tm
Copy link
Contributor Author

Again, awesome work! Can't wait to see whether I can get Delta Client running in visionOS

Thanks! I appreciate your time looking over the PR, I still have yet to run it as I am in the midst of re-certing my entire org as something apparently destroyed my ability to codesign, hoping to catch up to where you are at soon 😆. Additionally, I think we can just close #32 -- however; for perhaps some more entry level developers just getting into SwiftUI development, I wonder if there is a way to alleviate some of the headache involved with the code-signing process (if there is anything that can be done), to ease users into the bundler.

Aw man, Delta Client relies on some packages which don't compile for visionOS yet. Looks like it might be a bit more work than I was hoping for.

Agh! I'm sorry to hear that, any dependencies in particular?

@stackotter
Copy link
Owner

I wonder if there is a way to alleviate some of the headache involved with the code-signing process (if there is anything that can be done), to ease users into the bundler.

I have been occasionally trying to figure out how Xcode's auto provisioning works, but they keep it pretty secretive, and it's so annoying for third party tool devs like me.

One idea I had was to possibly generate dummy xcodeprojs that can be used to trick xcode into generating provision profiles automatically.

Anyway, you shouldn't need to do any codesigning to run apps on the simulator (I didn't).

Agh! I'm sorry to hear that, any dependencies in particular?

swift-unisocket, which is a dependency of swift-resolver, which delta client depends on to resolve dns SRV records. There might also be other dependencies that fail to build because Swift stops before it gets through all of the dependencies.

@furby-tm
Copy link
Contributor Author

One idea I had was to possibly generate dummy xcodeprojs that can be used to trick xcode into generating provision profiles automatically.

Not a bad idea! The codesigning for iOS and visionOS is pretty complicated, I'm used to macOS where you just manually notarize the distribution yourself and there's not much fuss.

Anyway, you shouldn't need to do any codesigning to run apps on the simulator (I didn't).

Wait, really? Lol.

$ bundler -v run -p visionOS
Building for production...
Build complete! (0.45s)
debug: Running command: '/usr/bin/env' with arguments: ["git", "rev-parse", "HEAD"]
error: Must specify `--identity`, `--codesign` and `--provisioning-profile` when '--platform visionOS'

I just assumed it was a must, because this is all I got otherwise when I tried to run it.

@stackotter
Copy link
Owner

bundler -v run -p visionOS

You need to use the visionOSSimulator platform instead to target the simulator

@furby-tm
Copy link
Contributor Author

bundler -v run -p visionOS

You need to use the visionOSSimulator platform instead to target the simulator

GOOD GOD 🤣 That worked. Thank you!

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 20, 2023

swift-unisocket, which is a dependency of swift-resolver, which delta client depends on to resolve dns SRV records.

That is infuriating, it's due to things like this if I recall correctly:

#if os(iOS)
import UIKit
import SwiftUI
#elseif os(macOS) || os(tvOS) || os(watchOS)
import Foundation
import SwiftUI
#else
import Foundation
#endif

I was able to build all of Vapor and some other dependencies like RealmSwift all bundled together in a visionOS app, but it took a hectic amount of adding || os(visionOS) everywhere and it was all temporary work that I threw out at the time.

But as far as I know, everything should build on visionOS, it's just missing imports due to cases like the above, simple solution is create a package as a product dependency of the libraries you need with an @_exported import of what you're missing in the package you create, and another @_exported import to import the package you created within each dependency library that is failing.

It's still annoying, but at least in that case, you just have this re-usable wall of imports monstrosity you can slap around to get things going in the interim.

@stackotter
Copy link
Owner

But as far as I know, everything should build on visionOS, it's just missing imports due to cases like the above, simple solution is create a package as a product dependency of the libraries you need with an @_exported import of what you're missing in the package you create, and another @_exported import to import the package you created within each dependency library that is failing.

Ok nice, it's good to hear that from your experience it's mostly just import problems. Maybe I'll give it a crack later (or see if someone else wants to give it a crack).

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 20, 2023

I think that may be better, perhaps, but not sure, having this field in here by default as well: UIApplicationSceneManifest

App doc

Bad ref, updated link

@stackotter
Copy link
Owner

having this field in here by default as well: UIApplicationSceneManifest

Is that one recommended to have for all visionOS apps? If so, yeah that seems sensible to me. Eventually I want to aim to have generated Info.plist's match the ones Xcode generates for maximum compatibility.

@furby-tm
Copy link
Contributor Author

furby-tm commented Aug 20, 2023

Is that one recommended to have for all visionOS apps?

Yeah, the docs seem a bit all over the place at the minute, looks like tons of new plist values which is probably just unstable API I think, things are likely fluid I imagine, until visionOS is at least a full version or two out.

UISceneSessionRoleImmersiveSpaceApplication looks important as well.

Here we go, this is their HelloWorld.xcodeproj, that might be a good model for sensible defaults.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>UIApplicationSceneManifest</key>
	<dict>
		<key>UIApplicationSupportsMultipleScenes</key>
		<true/>
		<key>UISceneConfigurations</key>
		<dict/>
	</dict>
	<key>UINativeSizeClass</key>
	<integer>1</integer>
</dict>
</plist>

Copy link
Owner

@stackotter stackotter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome 👌 looks good now, I'll merge once the workflows complete

@furby-tm
Copy link
Contributor Author

Awesome 👌 looks good now, I'll merge once the workflows complete

Great! -- I am loving this bundler! Thanks for your time with all this.

Looking forward to this bold swifty future 🦄.

@stackotter
Copy link
Owner

Great! -- I am loving this bundler! Thanks for your time with all this.

Yay, I'm glad you're enjoying it! 🎉

Looking forward to this bold swifty future 🦄.

😎

@stackotter stackotter merged commit 05bef32 into stackotter:main Aug 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants