Is Xcode still the official Apple IDE for developing in Swift?

Yeah, CLion worked well for a while, but now that the official Swift plugin has been sunsetted, its value will decrease soon.

Xcode + SPM is the official IDE & dependency manager for all things mobile and desktop. Anything else is just a game of roulette. When did anyone last see the OS minimum moved from iOS 7 for a cocoa pod?

After having simply tried to compile my packages using VSCode, i can already say that the errors being reported are far more useful than xcode's ones. Dependencies problems are simply stated (incorrect local paths in my case), whereas xcode simply seems to totally collapse.

So yes, i'll definitely try to keep investigating that solution.

2 Likes

Bit of a tangent, but it seems to me that many long time developers on Apple platforms have long since given up on filing bug reports. I understand that we should still be filing reports, and that the lack of responses is something we should expect and accept, but it really does strain the first/third party developer relationship.

Serious thought should go into how to bring some humanity and connection back into it. Filing into a void, year after year, is soul destroying, and I don't begrudge anyone who's given up on it entirely.

17 Likes

Full ACK, though that would require massive structural changes at Apple, and I don‘t see the pressure high enough for them to do it. :pensive:

2 Likes

I'm not an Apple insider by any stretch of the imagination, but I suppose the problem is that there are tens of millions of app developers, and obviously the Xcode team is nowhere near that. I have to imagine that they get a Tsunami of dupes for every major bug.

That said, I've gotten info requests from them before, and a bunch of dupe notices, so that's something.

And as I think about it, I can also imagine that their concerns aren't just about their famous secrecy, but also security, not only of the products, but of the people. You might have a couple of unsafe characters in any crowd, but when the crowd numbers in the millions, it approaches certainty.

1 Like

The obvious solution to that is to open up the bug tracker, so that third party devs can avoid posting dupes. Though as you say, Apple's secrecy would almost certainly never allow that, even if it would lead to a massive improvement to first/third party developer relations and to the quality and effectiveness of issue tracking. The right thing to do is the impossible thing to do.

Which is why I say "serious thought". If Apple want to improve the situation, while also maintaining their extreme secrecy, other less obvious smart ideas will be necessary.

I do believe though that it would be possible to partially open up issue tracking, while still maintaining secrecy, if done carefully. But I don't believe it's something Apple are willing to consider.

4 Likes

It's a lot of extra work, maintaining a public facing bug database, and while I agree it'd be nice, it's not totally clear that it'd be truly useful, i.e. getting faster solutions, or better. In fact, it may be that for every 100 devs who have given up, there's one or two who haven't, and this is sufficient information to cover known bugs.

I spent a couple of decades in online community building and community management, part of that time focused on software support communities. The one big thing I learnt was that open forums are less work than closed ones.

With a closed system you have to duplicate effort for every individual with a problem, even if that's just marking things as dupes. (And often you can't just scan an issue and immediately recognise it as a dupe - you have to go through the motions first, sucking up more time). With an open system a lot of communication simply goes away, because readers often find their answer without having to post at all.

The challenges are in things like dealing with internal devs making publicly visible statements. Developers aren't all trained or competent in public communication, so it presents challenges, especially for a company as obsessed with public appearances as Apple. Though they do seem to manage quite well with this Swift forum :man_shrugging:t2:

5 Likes

I can understand the cost comment, albeit for $3 Trillion dollar corporations (…still growing) I might not consider it that strongly, I think it is more of a You problem (you being Apple in this case) to support the devs that are also more than fractionally responsible for your success (for a great mobile OS that suffered a bit due to lack of third party developers you can ask MS about Windows Phone ;)).

The current way Bug Reports work where people submit bugs into a void where in lots of cases whether the bug is fixed or not they get no feedback, where sending duplicate bugs is the best way to signal / raise the importance of the bugs (given how the system is this process is likely not very automated so you are taking a problem and making it worse).

External Devs’ privacy needs (I am talking about the code they publish and the bugs they report) should not be something we use as a pretext to hide behind… people can be asked to choose whether their bug goes to an internal only database (but then we still have a problem of Apple not being responsive, devs that fix the problem not being the ones replying to bugs and the incentive for bug reviewers likely being tilted to close as many bugs as possible rather than the positive resolution or experience and that has negative side effects too).

It is not like we do not have other companies with bug report systems. Even on hand consoles like PlayStation the public might not see the bugs but other registered developers can.

Are we really discussing whether a more open and transparent system that avoided the need to file tons of similar bug reports instead of adding oneself to an existing bug would be better or worse?

We do not have an official survey to see what the users of this service think (tons and tons of devs would pay $199 instead of $99 a year to have a much better Bug Reporter service if that is the requirement albeit I think Apple should cover this cost as part of the 30% dev share too), it it would be nice to collect an open question about how a seasoned developer would introduce a new developer to the Bug Reporter: Dave Snowden - How leaders change culture through small actions - YouTube (really good section here about advocacy built into data and how to run surveys effectively).

8 Likes

To be clear, I am not talking about the privacy needs external devs, many of whom are the face of small businesses or at least the sole support contact of their app, and therefore must consider their own security individually. I'm talking about Apple's devs, who effectively have millions of customers. The company has a duty to consider their safety. But as I said, I'm no insider, so I can't truly speak to the needs they perceive.

The main setback for me to file a bug report via "Feedback Assistant" is that - there is no way to search for an issue previously filed by someone else, nor a way to share a public accessible link to others that can add comments or details to the issue. :slightly_frowning_face:
In the past there was the public-facing Jira https://bugs.swift.org website and "openradar" from contributing developers, which were more or less useful for finding an issue online. Both are now dormant for a long time.
Which pushed me to use StackOverflow, only knowing that I won't get an official feedback from Apple…

1 Like

Swift moved from Jira to GitHub Issues. The issue tracker is still public.

7 Likes

I am sorry, but I do not see how, if you could have the Bug Reporter system searchable and public how would the privacy of the individual be affected. I think you can have a system that does not endanger people but is still way more open and useful than it is now where developers on both sides (that may want to communicate to each other without layers of intermediaries that do not seem to be incentivised to keep third party and internal devs happy, but closing bugs as rapidly as they can as their main KPI).

Sometimes it seems to be a reverse logic that starts from a conclusion that this is the right solution because it is the current Apple solution (yet it is the current solution only for iOS and Xcode and other internal frameworks, but somehow for LLVM, Swift, etc… all that can be handled in public forums and big reporters where people put first name and last name… :man_shrugging:).

My ideas about this come from my own experience running an issue tracking system for internal devs and the discussions we had regarding customer bug reporting. Issue tracking systems seem to be best when the discussions can be freewheeling and open, which doesn't mesh with having almost any security considerations. Internal devs needing to use alternate names is an irritation at best, and people often reveal minor personal details about themselves without thinking, such as vacations, moving house, etc, when they feel obligated to explain why some work will be delayed. Training a handful of public facing people is one thing, training every single dev and checking on it is quite another.

1 Like

Yeah, you get used to the weird issues between Xcode’s legacy build system and SPM. There are a lot of edge cases. I don’t envy those just starting out in Xcode. I think at that point it has eclipsed CocoaPods.

I hope we will see Xcode fully adopt SPM for Apple platforms eventually. Playgrounds Apps might be a proving ground for that. If only it could do macOS, visionOS, and watchOS…

1 Like

one thing i have noticed is if you create an ios xcode playgrounds project (this is distinct from 'xcode playground'), the whole thing is just a swift package project (including specifying an ios app target w/dev-team id, entitlements etc in the package.swift file) so i think there are signs apple gets that message (one can hope) ^_^

3 Likes

Yes, I've noticed the same. I've thought that is a sign that Apple gets it, but just isn't ready to release to the masses yet.

I have been developing in a couple of languages.
Swift is pretty cool but xcode is ruining it for me. The VsCode plugin is pretty good but since I updated to the latest xcode I can't debug my tests anymore.

Anyway just came here to say that yes, the vscode plugin is pretty good and I hate xcode from the bottom of my heart. No shade to those who enjoy it.