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 < > [email protected]> 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 > > [email protected] > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
