401–410 of 441 posts
Earlier quoted context omitted.
Sure, if you write the GUI portions in the native toolkit and factor out the backend into your cross-platform language of choice.
I would argue that's not really a "first-class" developer experience from the perspective of developing for Apple products on a Mac.
Earlier quoted context omitted.
Lack of knowledge of your dependency tree isn't really an excuse here. If you're submitting your application to an App Store -- where one of the express purposes is that customers know the application is safe -- then having an unknown dependency is not really a good argument.
How are you sure that your code gets compiled properly? Do you read the assembly generated for the processor and the source code for your compiler? Are you sure that your machine code gets run properly? Do you test the CPU hardware and all the logical gates and whatnot so that they respond to the schemes and it passes the electric current properly? Like xkcd 378, we could follow this logic quite deep. At some point y…
I don't think anyone is suggesting that you should.
Earlier quoted context omitted.
Creating a Developer ID certificate requires a paid Apple account. Hardly free.
I think only a distribution certificate requires a paid account.
Earlier quoted context omitted.
I would argue that's not really a "first-class" developer experience from the perspective of developing for Apple products on a Mac.
The "first class" experience for developing on a Mac would be to develop only for the Mac. If you're not doing that, your job is going to be a bit more difficult.
Earlier quoted context omitted.
The "first class" experience for developing on a Mac would be to develop only for the Mac. If you're not doing that, your job is going to be a bit more difficult.
Yes, I'm aware. But it's a bit weird to say the developer experience on Linux is first-class. For things that don't have a GUI, sure. But that's not what the discussion was about.
Earlier quoted context omitted.
I think only a distribution certificate requires a paid account.
Now you've thrown me a curveball. I will have to test. I think last time I looked, Developer ID is considered a distribution certificate and requires payment.
Earlier quoted context omitted.
> Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking? That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.
And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along. That’s what happens when you focus on developers instead of users. How much smaller would Windows be if they didn’t have all of these backwards compstible hacks? Hell, they had a h…
Earlier quoted context omitted.
Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.
Not full knowledge. But you should know about every single dependency, know what they do and if they're from a trustworthy source. Being able to say with confidence that you aren't installing malware on your customers machines is the least you can do. On the developer side there's more though, you should know what their release cycles are like, how they manage compatibility, how long they support older releases etc.…
Earlier quoted context omitted.
I suspect that most devs don't do that. I can't imagine finding the time fir that.
Who do you imagine is responsible for making sure your app doesn’t contain malware? The only answer is that as a developer, you are responsible. Yes, we have to make calculated risks. But the buck stops at you. There is nobody else who can take responsibility for the contents of your app.
Earlier quoted context omitted.
Apple has banned the use of private APIs for years. It's only anticompetitive if they selectively apply those rules.
They have selectively applied them to themselves for ages as far as I know. Which must be regarded as anti competitive to some extent. It's also pretty much a straw man kind of argument around the public/private API distinction as important to prevent applications from breaking, as it seems to be the rule rather than the exception that lots of apps break on iOS updates anyway. They don't seem to care that much, but i…
This only affects the App Store, which Chrome quite purposely is not part of and which the vast majority of Apple apps aren't distributed through.
> They don't seem to care that much, but it could be a good way to make sure it's harder for eg Chrome to compete with Safari. Simply make the API they have to use a bit slow and inefficient.
My understanding is that the inefficiencies in question come from a need to bridge from cross-platform code into the public APIs.
For example, one of the private functions mentioned was needed to treat mach ports as file descriptors - not needed if you are using the proper API to deal with ports.
My understanding is the CoreAnimation private calls are because the layers are rendered and composited externally and CA is only being used for display. Because the rest of CA is skipped, it can't determine a list of partial changes and thus performs a lot more work than necessary. The Private calls are being used to force CA to skip rendering parts of parts of the display. Safari doesn't need to do this because they are using the proper API for the entire pipeline.