-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Conversation
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? |
There was a problem hiding this 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).
@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
|
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).
That sounds like it probably affects iOS support too; open an issue for that with some details and I can look into it later.
Yeah, it's a bit confusing lol, I think it's mostly correct. The only thing that seems wrong is |
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. |
Looks like ios-deploy is just an objc cli which uses lldb to install apps on devices (with a python lldb script) |
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. |
@stackotter I noticed I hadn't added the change for the I have made that required change here. |
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. |
Ah yep, good catch 👌
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)
That would be pretty awesome
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).
Thank you! 🙏 That means a lot
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. |
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 🍷
|
There was a problem hiding this 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)
Sources/swift-bundler/Bundler/SwiftPackageManager/SwiftPackageManagerError.swift
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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
I have found that I needed two changes to get visionOS support working. Line 29 of Again, awesome work! Can't wait to see whether I can get Delta Client running in visionOS |
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. |
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.
Agh! I'm sorry to hear that, any dependencies in particular? |
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).
|
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.
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. |
You need to use the |
GOOD GOD 🤣 That worked. Thank you! |
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 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 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. |
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). |
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. |
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>
|
There was a problem hiding this 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
Great! -- I am loving this bundler! Thanks for your time with all this. Looking forward to this bold swifty future 🦄. |
Yay, I'm glad you're enjoying it! 🎉
😎 |
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! 😆