https://developer.apple.com/bug-reporting/ For anyone who signs this, make sure you throw a report at em as well!
And see also http://fixradarorgtfo.com
Dear Apple
31–40 of 211 posts
Re: Dear Apple
#32Just stop pushing apps for iProducts. When all the major apps stop adding features for a while Apple will focus on getting developers back or customers switch to Android.
It's an unrealistic advice. It's easy to say it when your income is not dependent on these apps. But if you have an app in a marketplace that pays your bills, you can't afford to risk it just because you don't like dev tools...
It's only unrealistic if you aren't willing to adapt to changing market conditions.
Re: Dear Apple
#33It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.
The one that's been getting me lately is the split between Xcode 7/Swift 2.2 and 8/3. We have an older project in Swift 2 (yes, it's slated to get changed over, just not yet), and new work on a project in 3. If I try to open one while the other is already open, one of the Xcodes invariably freezes or crashes. I will say, though, that I've always liked IB (though not storyboards). But then there's the wonderful "Oh, y…
Can you still submit apps with Xcode 7?
In response to your problem, having done the Xcode Old/Xcode New dance every year since 2012, I got into the habit of making sure they are never running concurrently. Things get even worse if you run xcodebuild on the command line while a different UI version is running.
Re: Dear Apple
#34Earlier quoted context omitted.
It's an unrealistic advice. It's easy to say it when your income is not dependent on these apps. But if you have an app in a marketplace that pays your bills, you can't afford to risk it just because you don't like dev tools...
It's only unrealistic if you aren't willing to adapt to changing market conditions.
But the market conditions are what's holding us in place.
Re: Dear Apple
#35Just stop pushing apps for iProducts. When all the major apps stop adding features for a while Apple will focus on getting developers back or customers switch to Android.
Yup, that. Vote with your keyboards. Apple writes software with the same tools and languages - if they considered this stuff a problem, they'd have fixed it by now. Besides, Apple has mechanisms for feedback, and it's not open letters on GitHub.
> if they considered this stuff a problem, they'd have fixed it by now
It's not good but it's workable. Which Apple accepts as a reason to focus very few resources on dev tools.
Re: Dear Apple
#36It's absurd to have to beg the wealthiest software company in the world for what should be considered really basic stuff. Xcode is consistently unstable, slow, missing simple essential functionality (like refactoring), and Apple's interface builder is something that most experienced Apple devs know to run for the hills from.
That very wealth is what's insulating them from the long-term reality of the choices they're making. It's a trap!
Indeed, Apple has the high-tech equivalent of "dragon sickness", in a nod to Tolkien.
Google has a long road ahead of it, but it looks like they have the right pieces in place where I see small, incremental improvements each year, so maybe they're the tortoise. Milestones on that long road are like migrate away from Dalvik, fix business model / monetization issues with the Android marketplace, switch to vector-based canvas blitting, rationalize API support for different manufacturer-added features, and so on. What would be interesting is if they steal Apple's developer thunder by capitalizing upon open source and their in-house build system, and out-flank Apple's developer mindshare, by creating a developer-oriented ecosystem.
Imagine if you could hook up your own Docker container that Google's build infrastructure then taps to build your Android app...but all the open source your app depends upon are in their build infrastructure, with near-instant feedback on build and CI problems of the open source bits operating at a massive scale. App development shifts to a posture where open source frameworks/modules/libraries that already power a lot of software are orders of magnitude more convenient to develop under this ecosystem, and the agility/efficiency of all those Android developers coalescing around common open source components online in a single build and CI ecosystem far outstrips Apple-based developers stuck with XCode and their own person-oriented toolchains. Apple has nothing in the pipeline remotely like that kind of ecosystem. Google would also get big data-based insight into phone app development trends in real-time that Apple could only dream about. Google's phone app development OODA loop would tighten considerably smaller than Apple's.
I also wonder if Google and Microsoft could find benefits to team up to replace Dalvik with CLR, and then Microsoft Visual Studio becomes a first-class citizen on Linux for building CLR-based apps on Android.
Re: Dear Apple
#37Wow, it's that bad for developers of their own platform? I do rails development and left OSX for linux a few years ago after finding all the custom song & dance to do things on apple was painful. Not a day goes by I am not grateful for doing that, i am much happier doing web dev on a linux box.
But I was under the impression Apple at least took care of the devs who work on their platforms.
As someone else has noted: vote with your keyboard. I do ROR web development in part because I am free of many of the constraints other devs must face on custom platforms.
If you don't like doing dev with Apple, don't do dev with Apple. Either pick better tooling (if available) or ditch the platform (if possible).
Re: Dear Apple
#38I don't think it's considered a problem by the team at Apple, or even by some developers, but I would love a more stable Swift language. The number of changes per version * the number of projects in the world is causing a large amount of work and instability. This is contributing to the low tool quality as well.
Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code. Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions
Yes I know that's what Swift 3 was trying to do, that's what I don't agree with. In my opinion the tradeoffs are just not worth it.
Whatever happened to graceful deprecation of older language features an APIs? They invalidated all the related example code online and created a ton of mandatory work for all iOS developers within a 1 year timeframe, that's nuts. In my opinion :)
Re: Dear Apple
#39I don't think it's considered a problem by the team at Apple, or even by some developers, but I would love a more stable Swift language. The number of changes per version * the number of projects in the world is causing a large amount of work and instability. This is contributing to the low tool quality as well.
Swift 3 had a purposeful effort to prioritize syntax-impacting changes and API changes as possible with the idea that Swift 4 and beyond would have backward compatibility for Swift 3 code. Swift 4/5 will establish ABI compatibility, so that binary swift libraries will work across compiler versions
[deleted]
Re: Dear Apple
#40Earlier quoted context omitted.
It's an unrealistic advice. It's easy to say it when your income is not dependent on these apps. But if you have an app in a marketplace that pays your bills, you can't afford to risk it just because you don't like dev tools...
It's only unrealistic if you aren't willing to adapt to changing market conditions.
This may not be what HN readers want to hear, but users, not developers, have the primary influence over what the market is.