Skip to content

Add support for App Extensions#97

Merged
kabiroberai merged 51 commits intoxtool-org:mainfrom
erikbdev:main
Jul 14, 2025
Merged

Add support for App Extensions#97
kabiroberai merged 51 commits intoxtool-org:mainfrom
erikbdev:main

Conversation

@erikbdev
Copy link
Copy Markdown
Contributor

@erikbdev erikbdev commented May 27, 2025

This pull request adds support for Apple's App Extensions.

Closes: #45

Copy link
Copy Markdown
Member

@kabiroberai kabiroberai left a comment

Choose a reason for hiding this comment

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

this is great, thanks! left one quick comment but feel free to ping me once it's ready for broad review.

Comment thread Sources/PackLib/Packer.swift Outdated
@erikbdev
Copy link
Copy Markdown
Contributor Author

@kabiroberai I am 90% done with App Extensions (excluding ExtensionKit, iMessage).

The only thing missing is ensuring XcodeProj generates a valid folder with all products.

If you like you can go over my code base and let me know if you have any feedback. :)

@erikbdev erikbdev marked this pull request as ready for review June 1, 2025 10:44
@kabiroberai
Copy link
Copy Markdown
Member

@erikbdev thanks, I'll look at this as soon as I can! In the meantime do you mind fixing the SwiftLint failures? You can run make lint to lint locally.

Comment thread Sources/XToolSupport/DevCommand.swift Outdated
Comment thread Sources/PackLib/Planner.swift
Comment thread Sources/PackLib/Packer.swift Outdated
Comment thread Sources/PackLib/Packer.swift Outdated
Comment thread Sources/XKit/DeveloperServices/OpenAPI/ASCKey.swift Outdated
Comment thread Sources/PackLib/Planner.swift Outdated
Comment thread Sources/PackLib/Planner.swift
erikbdev and others added 2 commits July 13, 2025 17:14
Will update in another pull request.

This reverts commit 7749f2b.
kabiroberai pushed a commit that referenced this pull request Jul 14, 2025
This pull request resolves potential clock drift between ASC and bearer
token.

Ref: #97 (comment)
Copy link
Copy Markdown
Member

@kabiroberai kabiroberai left a comment

Choose a reason for hiding this comment

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

lgtm, this is great! will do some final testing and merge shortly if everything works.

A few things we probably want to do as followups:

  1. [High priority] support ExtensionKit
  2. [Medium priority] deduplicate frameworks. i.e. if a framework is used across multiple products (multiple extensions or main target + extension), pull it out into the main target's Frameworks directory and reuse it.
  3. [Low priority] create an upstream SwiftPM issue about describe and show-dependencies having logs that are sent to stdout. I think the ideal fix here would be for describe to offer a -o parameter because that entirely skirts around the issue of noisy stdout logs.

@kabiroberai
Copy link
Copy Markdown
Member

kabiroberai commented Jul 14, 2025

Another idea for a followup: I wonder whether a shorthand to avoid requiring extension.[].infoPlist would be useful. For example,

extensions:
- product: MyWidget
  NSExtensionPointIdentifier: com.apple.widgetkit-extension
- product: MyGenericExt
  EXExtensionPointIdentifier: com.example.generic

or maybe

extensions:
- product: MyWidget
  extensionPoint: com.apple.widgetkit-extension
- product: MyGenericExt
  type: ExtensionKit
  extensionPoint: com.example.generic

@erikbdev
Copy link
Copy Markdown
Contributor Author

extensions:
- product: MyWidget
  extensionPoint: com.apple.widgetkit-extension
- product: MyGenericExt
  type: ExtensionKit
  extensionPoint: com.example.generic

This looks interesting, we could also possibly infer the type of extension based on the extensionPoint value. One thing to note is that some extensions require additional keys, e.g. "NSExtensionPrincipalClass" or "NSExtensionMainStoryboard."

This is just the provisioning side, still need to support bundling into the Extensions dir in a separate PR
we’re using bForce=true in zsign so the outer bundle will overwrite the inner bundle
@kabiroberai
Copy link
Copy Markdown
Member

we could also possibly infer the type of extension based on the extensionPoint value

hmm we could but that feels a bit too magical to me. I think being explicit about it (either via type: ExtensionKit or the NSExtension/EXAppExtensionAttributes key) is ideal.

One thing to note is that some extensions require additional keys, e.g. "NSExtensionPrincipalClass" or "NSExtensionMainStoryboard."

I think we should just require an Info.plist in these cases. As newly introduced extension points move towards ExtensionKit, this will hopefully become less necessary over time.

@kabiroberai kabiroberai merged commit edd6b90 into xtool-org:main Jul 14, 2025
9 checks passed
DanielLiebesk added a commit to DanielLiebesk/xtool that referenced this pull request Aug 14, 2025
This pull request resolves potential clock drift between ASC and bearer
token.

Ref: xtool-org/xtool#97 (comment)
XavierZhengwa added a commit to XavierZhengwa/xtool that referenced this pull request Aug 14, 2025
This pull request resolves potential clock drift between ASC and bearer
token.

Ref: xtool-org/xtool#97 (comment)
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.

Support for App Extensions (e.g. Widgets)

2 participants