Swift Package Manager 3.0 Project Status

Hi everyone,

The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.

## Release Plan

Our `swift-3.0` branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).

Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!

## Project Status

We have accomplished a lot in the past year, but the package manager still has a long way to go and there are a number of areas where we know there to be significant limitations:

* The current dependency resolution strategy is not able to resolve complex graphs with conflicts. This has not proved to be a major problem so far -- we suspect because of the relative youth of the ecosystem -- but this is an area known to need significant work.

* It can be quite difficult to deploy binaries built with the package manager, and there are little to no controls over some of the necessary parameters (like static versus dynamic linking, or management of linker RPATH values). See SR-648, SR-674, SR-1968, SR-2048.

* We are missing important workflows for a number of typical development scenarios: (1) lock files / version pinning, (2) editable packages (SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring dependencies (SR-679).

* Our documentation needs more work.

## Future Directions

The immediate focus for the package manager is on features and bug fixes which address the issues mentioned above and improve the usability of the tool, but which do not require significant changes to the current overall design (in particular, we would like to defer major changes to the manifest API until we have resolved more of the workflow issues).

Towards that end, the things we are interested in tackling in the short term are:

* Editable packages (SE-0082)
* Improved dependency graph resolution & diagnostics:
  * Fine-grained package dependencies
  * Branch support (SR-666)
  * Version lockfiles/pinning
  * Dependency name collisions
* Stabilizing the manifest API for Swift 4
* Focused improvements to the Xcode project generator (SR-1653, SR-1655, SR-1740, SR-1741).
* Support for managing supported Swift language versions, as this feature develops in the compiler.
* Improvements to build consistency (SR-1708, SR-2182).
* Improvements to documentation (SR-2179, SR-1586).
* Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261, SR-2270, SR-2271).
* Performance

Once we are on a more stable footing, there are many things we could tackle next. Here are some of the areas we are interested in investigating, to see if any of them fit in the scope of Swift 4:

* Evaluating the role for a centralized package index
* Extending the package model to support more use cases (extensible build targets, custom source layouts, more expressive product definition APIs)
* Package metadata such as license and attribution information
* Supporting repositories containing multiple packages
* Support for third-party testing frameworks
* Support for cross-compilation

We hope that gives some picture of where the Swift package manager is headed. It's an exciting time for Swift development, and we can't wait to see what the year holds!

- Daniel

(*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself powered by a Swift Package.

What are the near term plans–if there are any–for supporting iOS? I made
the mistake of assuming support was a couple months away at most when the
package manager was announced. I plan to port my iOS/Mac frameworks over as
soon as I can.

TJ

···

On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift-evolution < swift-evolution@swift.org> wrote:

Hi everyone,

The package manager was a brand new project released with open source
Swift, and we have made significant progress as part of Swift 3.0. Starting
from that humble beginning we now estimate there are around 3,500 Swift
Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem
with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and
Zewo), tooling and infrastructure (like the IBM Package Catalog and
swiftenv), or simply adoption by existing popular Swift frameworks (like
Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the
upcoming Swift 3.0 release, some project status, and a bit about our future
directions.

## Release Plan

Our `swift-3.0` branch was cut along with the Swift compiler project and
will be our final release branch for the Swift 3.0 release. At this point,
the only changes we anticipate taking onto the branch are ones that have
significant impact on our current user base (primarily those focused on
server-side Swift development).

Swift 3.0 will be the first official release including the package
manager, which is also shipping as a command line tool inside Xcode 8. We
are looking forward to seeing the ecosystem develop as these tools GM
alongside the now source stable Swift 3.0!

## Project Status

We have accomplished a lot in the past year, but the package manager still
has a long way to go and there are a number of areas where we know there to
be significant limitations:

* The current dependency resolution strategy is not able to resolve
complex graphs with conflicts. This has not proved to be a major problem so
far -- we suspect because of the relative youth of the ecosystem -- but
this is an area known to need significant work.

* It can be quite difficult to deploy binaries built with the package
manager, and there are little to no controls over some of the necessary
parameters (like static versus dynamic linking, or management of linker
RPATH values). See SR-648, SR-674, SR-1968, SR-2048.

* We are missing important workflows for a number of typical development
scenarios: (1) lock files / version pinning, (2) editable packages
(SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring
dependencies (SR-679).

* Our documentation needs more work.

## Future Directions

The immediate focus for the package manager is on features and bug fixes
which address the issues mentioned above and improve the usability of the
tool, but which do not require significant changes to the current overall
design (in particular, we would like to defer major changes to the manifest
API until we have resolved more of the workflow issues).

Towards that end, the things we are interested in tackling in the short
term are:

* Editable packages (SE-0082)
* Improved dependency graph resolution & diagnostics:
  * Fine-grained package dependencies
  * Branch support (SR-666)
  * Version lockfiles/pinning
  * Dependency name collisions
* Stabilizing the manifest API for Swift 4
* Focused improvements to the Xcode project generator (SR-1653, SR-1655,
SR-1740, SR-1741).
* Support for managing supported Swift language versions, as this feature
develops in the compiler.
* Improvements to build consistency (SR-1708, SR-2182).
* Improvements to documentation (SR-2179, SR-1586).
* Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261,
SR-2270, SR-2271).
* Performance

Once we are on a more stable footing, there are many things we could
tackle next. Here are some of the areas we are interested in investigating,
to see if any of them fit in the scope of Swift 4:

* Evaluating the role for a centralized package index
* Extending the package model to support more use cases (extensible build
targets, custom source layouts, more expressive product definition APIs)
* Package metadata such as license and attribution information
* Supporting repositories containing multiple packages
* Support for third-party testing frameworks
* Support for cross-compilation

We hope that gives some picture of where the Swift package manager is
headed. It's an exciting time for Swift development, and we can't wait to
see what the year holds!

- Daniel

(*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself
powered by a Swift Package.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

It sounds like we may not get any heads up about any work on that level of
integration:

https://twitter.com/jckarter/status/766072626624073729

Which I guess also brings up the question of whether or not it will be done in
public (which might also be unanswerable).

···

--
Keith Smiley

On 08/17, T.J. Usiyan via swift-evolution wrote:

What are the near term plans–if there are any–for supporting iOS? I made
the mistake of assuming support was a couple months away at most when the
package manager was announced. I plan to port my iOS/Mac frameworks over as
soon as I can.

TJ

On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift-evolution < > swift-evolution@swift.org> wrote:

> Hi everyone,
>
> The package manager was a brand new project released with open source
> Swift, and we have made significant progress as part of Swift 3.0. Starting
> from that humble beginning we now estimate there are around 3,500 Swift
> Packages on GitHub (*), with more and more showing up every day.
>
> Since release, we have seen a rapid explosion in the package ecosystem
> with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and
> Zewo), tooling and infrastructure (like the IBM Package Catalog and
> swiftenv), or simply adoption by existing popular Swift frameworks (like
> Alamofire, SnapKit, SwiftJSON, and RxSwift).
>
> We wanted to lay out our plans for the package manager with regard to the
> upcoming Swift 3.0 release, some project status, and a bit about our future
> directions.
>
>
> ## Release Plan
>
> Our `swift-3.0` branch was cut along with the Swift compiler project and
> will be our final release branch for the Swift 3.0 release. At this point,
> the only changes we anticipate taking onto the branch are ones that have
> significant impact on our current user base (primarily those focused on
> server-side Swift development).
>
> Swift 3.0 will be the first official release including the package
> manager, which is also shipping as a command line tool inside Xcode 8. We
> are looking forward to seeing the ecosystem develop as these tools GM
> alongside the now source stable Swift 3.0!
>
>
> ## Project Status
>
> We have accomplished a lot in the past year, but the package manager still
> has a long way to go and there are a number of areas where we know there to
> be significant limitations:
>
> * The current dependency resolution strategy is not able to resolve
> complex graphs with conflicts. This has not proved to be a major problem so
> far -- we suspect because of the relative youth of the ecosystem -- but
> this is an area known to need significant work.
>
> * It can be quite difficult to deploy binaries built with the package
> manager, and there are little to no controls over some of the necessary
> parameters (like static versus dynamic linking, or management of linker
> RPATH values). See SR-648, SR-674, SR-1968, SR-2048.
>
> * We are missing important workflows for a number of typical development
> scenarios: (1) lock files / version pinning, (2) editable packages
> (SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring
> dependencies (SR-679).
>
> * Our documentation needs more work.
>
>
> ## Future Directions
>
> The immediate focus for the package manager is on features and bug fixes
> which address the issues mentioned above and improve the usability of the
> tool, but which do not require significant changes to the current overall
> design (in particular, we would like to defer major changes to the manifest
> API until we have resolved more of the workflow issues).
>
> Towards that end, the things we are interested in tackling in the short
> term are:
>
> * Editable packages (SE-0082)
> * Improved dependency graph resolution & diagnostics:
> * Fine-grained package dependencies
> * Branch support (SR-666)
> * Version lockfiles/pinning
> * Dependency name collisions
> * Stabilizing the manifest API for Swift 4
> * Focused improvements to the Xcode project generator (SR-1653, SR-1655,
> SR-1740, SR-1741).
> * Support for managing supported Swift language versions, as this feature
> develops in the compiler.
> * Improvements to build consistency (SR-1708, SR-2182).
> * Improvements to documentation (SR-2179, SR-1586).
> * Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261,
> SR-2270, SR-2271).
> * Performance
>
> Once we are on a more stable footing, there are many things we could
> tackle next. Here are some of the areas we are interested in investigating,
> to see if any of them fit in the scope of Swift 4:
>
> * Evaluating the role for a centralized package index
> * Extending the package model to support more use cases (extensible build
> targets, custom source layouts, more expressive product definition APIs)
> * Package metadata such as license and attribution information
> * Supporting repositories containing multiple packages
> * Support for third-party testing frameworks
> * Support for cross-compilation
>
>
> We hope that gives some picture of where the Swift package manager is
> headed. It's an exciting time for Swift development, and we can't wait to
> see what the year holds!
>
> - Daniel
>
> (*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself
> powered by a Swift Package.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Our stated plans here, and there hasn't been any change, is to leave building for iOS to Xcode. We have (very) limited support for doing that from SwiftPM via generated projects, and it would be nice to see that support deepen. However, there are a lot of limits to that approach and for something better we will need to wait for full Xcode integration. Unfortunately, we don't yet have a much better answer than this one from last year:

https://lists.swift.org/pipermail/swift-users/2015-December/000052.html

The reality is that we have a lot of work to do to make the package manager and its ecosystem a stable base for development... for *any* platform. We think its really important to have that base be solid so that it can grow successfully, which means we are prioritizing features that impact the package syntax, dependency resolution, and workflows. The scope of things we would need to tackle to directly build for iOS is just too long (remote testing, cross-compilation, code signing, entitlements, provisioning profiles) to try to do simultaneously.

Cheers,
- Daniel

···

On Aug 17, 2016, at 4:58 PM, T.J. Usiyan <griotspeak@gmail.com> wrote:

What are the near term plans–if there are any–for supporting iOS? I made the mistake of assuming support was a couple months away at most when the package manager was announced. I plan to port my iOS/Mac frameworks over as soon as I can.

TJ

On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift-evolution <swift-evolution@swift.org> wrote:
Hi everyone,

The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.

## Release Plan

Our `swift-3.0` branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).

Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!

## Project Status

We have accomplished a lot in the past year, but the package manager still has a long way to go and there are a number of areas where we know there to be significant limitations:

* The current dependency resolution strategy is not able to resolve complex graphs with conflicts. This has not proved to be a major problem so far -- we suspect because of the relative youth of the ecosystem -- but this is an area known to need significant work.

* It can be quite difficult to deploy binaries built with the package manager, and there are little to no controls over some of the necessary parameters (like static versus dynamic linking, or management of linker RPATH values). See SR-648, SR-674, SR-1968, SR-2048.

* We are missing important workflows for a number of typical development scenarios: (1) lock files / version pinning, (2) editable packages (SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring dependencies (SR-679).

* Our documentation needs more work.

## Future Directions

The immediate focus for the package manager is on features and bug fixes which address the issues mentioned above and improve the usability of the tool, but which do not require significant changes to the current overall design (in particular, we would like to defer major changes to the manifest API until we have resolved more of the workflow issues).

Towards that end, the things we are interested in tackling in the short term are:

* Editable packages (SE-0082)
* Improved dependency graph resolution & diagnostics:
  * Fine-grained package dependencies
  * Branch support (SR-666)
  * Version lockfiles/pinning
  * Dependency name collisions
* Stabilizing the manifest API for Swift 4
* Focused improvements to the Xcode project generator (SR-1653, SR-1655, SR-1740, SR-1741).
* Support for managing supported Swift language versions, as this feature develops in the compiler.
* Improvements to build consistency (SR-1708, SR-2182).
* Improvements to documentation (SR-2179, SR-1586).
* Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261, SR-2270, SR-2271).
* Performance

Once we are on a more stable footing, there are many things we could tackle next. Here are some of the areas we are interested in investigating, to see if any of them fit in the scope of Swift 4:

* Evaluating the role for a centralized package index
* Extending the package model to support more use cases (extensible build targets, custom source layouts, more expressive product definition APIs)
* Package metadata such as license and attribution information
* Supporting repositories containing multiple packages
* Support for third-party testing frameworks
* Support for cross-compilation

We hope that gives some picture of where the Swift package manager is headed. It's an exciting time for Swift development, and we can't wait to see what the year holds!

- Daniel

(*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself powered by a Swift Package.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

To elaborate on this slightly:

We plan for you to be able to write iOS Swift Packages, but rather than creating a complete iOS build system in SwiftPM, this will likely work by leveraging Xcode's build system. We think that great Xcode integration is a requirement before we will see mass SwiftPM adoption by the iOS developer community. Since Xcode is not part of the open source project, the schedule and specific plans for that work are not public – but there will be work done in the open source project to give SwiftPM a library architecture suitable for allowing it to integrate with IDEs like Xcode.

In the meantime, SwiftPM supports generating an Xcode project from a package, which you can then use to build for iOS if desired (with some additional configuration of the generated project). We're open to pull requests to improve this functionality as well. For now, I would not broadly recommend that iOS developers switch to a SwiftPM-based workflow for their production software using this interim approach.

There are a lot of improvements to make to the workflow and features of Swift packages, and many of those improvements should have an effect on the eventual Xcode integration. Our public focus is on building a solid open source base that can support a thriving Swift package ecosystem for years to come. We're grateful to the developers who are using SwiftPM today and providing us with valuable feedback; much of today's use is to support server-side Swift development. And we're excited to grow SwiftPM into a tool that will meet the needs of our broader developer community!

  - Rick

···

On Aug 17, 2016, at 7:43 PM, Daniel Dunbar via swift-build-dev <swift-build-dev@swift.org> wrote:

Our stated plans here, and there hasn't been any change, is to leave building for iOS to Xcode. We have (very) limited support for doing that from SwiftPM via generated projects, and it would be nice to see that support deepen. However, there are a lot of limits to that approach and for something better we will need to wait for full Xcode integration. Unfortunately, we don't yet have a much better answer than this one from last year:

https://lists.swift.org/pipermail/swift-users/2015-December/000052.html

The reality is that we have a lot of work to do to make the package manager and its ecosystem a stable base for development... for *any* platform. We think its really important to have that base be solid so that it can grow successfully, which means we are prioritizing features that impact the package syntax, dependency resolution, and workflows. The scope of things we would need to tackle to directly build for iOS is just too long (remote testing, cross-compilation, code signing, entitlements, provisioning profiles) to try to do simultaneously.

Cheers,
- Daniel

On Aug 17, 2016, at 4:58 PM, T.J. Usiyan <griotspeak@gmail.com <mailto:griotspeak@gmail.com>> wrote:

What are the near term plans–if there are any–for supporting iOS? I made the mistake of assuming support was a couple months away at most when the package manager was announced. I plan to port my iOS/Mac frameworks over as soon as I can.

TJ

On Wed, Aug 17, 2016 at 6:44 PM, Daniel Dunbar via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi everyone,

The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.

Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).

We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.

## Release Plan

Our `swift-3.0` branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).

Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!

## Project Status

We have accomplished a lot in the past year, but the package manager still has a long way to go and there are a number of areas where we know there to be significant limitations:

* The current dependency resolution strategy is not able to resolve complex graphs with conflicts. This has not proved to be a major problem so far -- we suspect because of the relative youth of the ecosystem -- but this is an area known to need significant work.

* It can be quite difficult to deploy binaries built with the package manager, and there are little to no controls over some of the necessary parameters (like static versus dynamic linking, or management of linker RPATH values). See SR-648, SR-674, SR-1968, SR-2048.

* We are missing important workflows for a number of typical development scenarios: (1) lock files / version pinning, (2) editable packages (SE-0082), (3) master/trunk-style development (SR-666), and (4) vendoring dependencies (SR-679).

* Our documentation needs more work.

## Future Directions

The immediate focus for the package manager is on features and bug fixes which address the issues mentioned above and improve the usability of the tool, but which do not require significant changes to the current overall design (in particular, we would like to defer major changes to the manifest API until we have resolved more of the workflow issues).

Towards that end, the things we are interested in tackling in the short term are:

* Editable packages (SE-0082)
* Improved dependency graph resolution & diagnostics:
  * Fine-grained package dependencies
  * Branch support (SR-666)
  * Version lockfiles/pinning
  * Dependency name collisions
* Stabilizing the manifest API for Swift 4
* Focused improvements to the Xcode project generator (SR-1653, SR-1655, SR-1740, SR-1741).
* Support for managing supported Swift language versions, as this feature develops in the compiler.
* Improvements to build consistency (SR-1708, SR-2182).
* Improvements to documentation (SR-2179, SR-1586).
* Improvements to diagnostics and usability (SR-879, SR-1388, SR-2261, SR-2270, SR-2271).
* Performance

Once we are on a more stable footing, there are many things we could tackle next. Here are some of the areas we are interested in investigating, to see if any of them fit in the scope of Swift 4:

* Evaluating the role for a centralized package index
* Extending the package model to support more use cases (extensible build targets, custom source layouts, more expressive product definition APIs)
* Package metadata such as license and attribution information
* Supporting repositories containing multiple packages
* Support for third-party testing frameworks
* Support for cross-compilation

We hope that gives some picture of where the Swift package manager is headed. It's an exciting time for Swift development, and we can't wait to see what the year holds!

- Daniel

(*) See https://github.com/czechboy0/swiftpm-packages-statistics, itself powered by a Swift Package.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

What special things are needed for iOS support? Isn’t it just another cross-compilation target (albeit one requiring code-signing)?

Karl

···

On 18 Aug 2016, at 03:04, Keith Smiley via swift-evolution <swift-evolution@swift.org> wrote:

It sounds like we may not get any heads up about any work on that level of
integration:

https://twitter.com/jckarter/status/766072626624073729

Which I guess also brings up the question of whether or not it will be done in
public (which might also be unanswerable).

--
Keith Smiley

I'm hoping that swiftpm never really has to deal with the complexities of code
signing and related problems like entitlements. But at the bare minimum it would
need to be able to create dynamic frameworks, optionally including resources
such as strings files or xibs, for consumption by your main app target.

I don't think we're too far away from this but that would need to happen first.
I would be happy to use swiftpm more like Carthage than CocoaPods. So as long as
it could create your frameworks and you could set them up in your project one
time this would totally be usable.

···

--
Keith Smiley

On 08/21, Karl wrote:

> On 18 Aug 2016, at 03:04, Keith Smiley via swift-evolution <swift-evolution@swift.org> wrote:
>
> It sounds like we may not get any heads up about any work on that level of
> integration:
>
> https://twitter.com/jckarter/status/766072626624073729
>
> Which I guess also brings up the question of whether or not it will be done in
> public (which might also be unanswerable).
>
> --
> Keith Smiley

What special things are needed for iOS support? Isn’t it just another cross-compilation target (albeit one requiring code-signing)?

Karl

Static frameworks would also be nice, since it is possible nowadays, and improves app startup time.

Apart from resources (SR-2866), build settings (SR-3948) is another thing that‘s a prerequisite to be usable, as se somehow need to set the iOS deployment target version.

More nice-to-have features are mentioned in this thread: Swift Package Manager Evolution Ideas

1 Like