SwiftPackageIndex Trends

[Sherlouk]

Hey 👋

Bit of an "out there" idea but curious what you folks think...

SwiftPackageIndex is beginning to understand a lot about the general 'stance' of Swift and Swift Packages/Swift Package Manager within the Apple community. I think it'd be awesome if there was an automated way to view and visualise this data in a digestible way.

From an anonymous perspective I'm quite a fan of what Mixpanel is able to do with their trends page allowing us to visualise the adoption of iOS and new devices way quicker and 'accurate' than what we get periodically from Apple themselves.

Some aspects which I personally think would be interesting are:

• Minimum OS Support

  • e.g. How many packages still support iOS 10?

• Platform/Product Targeting

  • e.g. How many work on Linux?
  • e.g. How many are designed for iOS vs macOS etc?

• Swift Support

  • e.g. When a new Swift version is released, what % work 'out of the box' vs are broken by the changes?
  • e.g. How many package still support Swift 3?
  • e.g. What version of Swift Package Build Tools are being used?

I know it's been spoken about previously about potentially adding a 'Popular Packages' page and I think this could be an extension to it. We have the data so why not share it?

Ultimately I find this sort of information interesting but it can also help to drive decision making by the developers who use the site!

[finestructure]

Hi James! :)

It'll definitely be interesting to look at some of the data in aggregate. We've sort of started doing that in a "static" fashion with our blog post about ARM builds.

Personally, I see this is a good first step to find out what piques peoples interest before full on embarking on a page that's driven by (perhaps costly) queries.

Some things unfortunately aren't even possible right now. For instance your first example regarding minimum OS support is not something we can answer. (You may be thinking of the platforms: clause in Package.swift but that's not how it works, unfortunately.)

Same for popular packages - apart from "Github stars" I don't see what metrics we would actually base this on. Perhaps number of forks in addition? When you say "we have the data", do you have some metrics in mind that I'm overlooking?

[finestructure]

Ah, I just checked the issue you linked to and I guess package dependencies would be a good signal 👍

[Sherlouk]

Definitely some valid points raised there Sven, and I definitely misunderstood (still misunderstand?) the purpose of platforms so scrap that one from the record 😛

This partly links into the "State of iOS" big questionnaire that Dave did - the results were really interesting to me (and some of my teammates) so can see how having some of this data (even if it were only updated once weekly 🤷‍♂️) would be hugely beneficial!

The examples I gave were just that though, I'm sure some of them are too niche and I'm likely to have missed some too!

[daveverwer]

I just posted some thoughts on popularity inspired by this thread, and my current feelings on it over in #393. Thoughts on the graphs are incoming!

[daveverwer]

I think the graphs are potentially interesting, especially around Swift versions. New Swift versions happen often enough that there's always the question of whether packages you use support your version of Swift, which is why we build the compatibility system! Having a general/global view of that is less useful, but it still might be interesting.

I don't think a graph of platform adoption is particularly interesting but maybe exposing some numbers about what percentage of packages support each platform might be a curiosity people might glance at occasionally. I'm less convinced on this one if I'm honest. 😬 Linux support is the only one that might be worth tracking historically, but Linux is such a niche within Swift, I'm not sure I'd prioritise building this feature just for that metric.

On the subject of server load to generate these numbers, my gut feeling says it wouldn't be too bad. The queries run to generate the numbers would only run once per day/week as we'd need to store the numbers permanently to get the historical view for the charts. The queries themselves might be heavy, but they'd not be tied to a page load.

If we prioritise this, we should do it for Swift versions first.