auxio

lkrupp said:

asdasd said:

crowley said:

Illusive said:

So they want us to buy untested rubbish so then can alter it as they see fit with every update? No, thanks. Long live sandboxing!

Untested rubbish?  What is this based on, the blog post didn't mention anything about testing?  Rogue Amoeba are a solid developer with a great track record, and they definitely test their software.  

He is talking about Apple testing, but that is perfunctory. Just to see if the app works and isn't using private API or breaching privacy. 

Developers using unsupported APIs has been problematic for decades. Developers have hooked into macOS without using a supported API to provide some feature or function. macOS gets updated and the user finds out their app has ceased to function because the hook no longer works. Developer is forced to update and/or remove the feature, then rage at Apple. Lather-rinse-repeat. And who does the user blame? “It worked before the update, now it doesn’t, therefore it’s Apple’s fault. Fix it NOW, Apple!”

In recent years Apple has locked down macOS more and more (kernel extensions, browser extensions, etc.) so we see it less. Developers rage.

I'll give you a counterexample to the argument that no developer ever needs to use unsupported APIs.

I worked at a company which made wall-mounted touch displays that were used in education.  Since they're used in classes with smaller children (or special needs students), we needed to put the toolbar at the bottom of the window so that children (or people in wheelchairs) could reach it.  There was no way to do this with the standard Mac toolbar.  We could have just created our own toolbar, but we wanted the app to have the standard look and feel of a Mac app (especially since Apple changes it slightly on every new version of MacOS).  We talked to Apple about it, showed them photos, and they actually provided us a private API to do what we needed.

Sometimes there genuinely are cases where you need to do something which isn't possible with the standard APIs.

gatorguy said:

lkrupp said:

Just what we need, Android ports to iOS. Remember those Windows ports to Mac OS...? Let me guess. Google will encourage developers to build their Android apps and then port them to iOS using Flutter where they will look goofy and not perform as well.

Or they can develop for iOS first and easily port to Android too using Flutter. I know we have a few dev's here who can comment with more insight. 

I haven't looked into it deeply, but here's a key point:

Developers create the code of the app in Dart, which is then passed through Flutter's rendering engine and framework, with both tools used to make the code work on each platform natively. The engine is shipped as part of the app package, along with the developer's code, which is used to run the app on the target device, like an iPhone or an Android tablet. 

So basically you develop in a programming language which isn't native to iOS (Dart), which then requires you to bundle a special engine with your app to translate the application UI + logic from Dart into the native iOS APIs.  Sounds a lot like programming in Java.  I've used a few of these types of cross-platform runtime translation engines over the years, and the problem for me is that you'll never get access to the latest platform features because you're always waiting for the engine to support them.  And, of course, if such features aren't available on every platform the engine supports, then you may never get access to them.  Or you'll have to do a bunch of work to get access to them -- e.g. create your own JNI libraries in Java.

EDIT: Found the process for how to get access to native iOS features (looks a lot like creating JNI libraries): https://flutter.io/platform-channels/

These engines are perfectly fine for simple apps which are doing common things, but not-so-great once you want to get outside of that sandbox and do more interesting things which require platform features which don't fall in that platform common denominator scenario.  But since most of Google's apps just go out to the web/cloud for everything they do, it works for them.

red oak said:

All of these millennial or Gen Z snowflakes are torpedoing their careers.  They are going to wake up 10 years from now wondering how the f* everything up so bad 

God forbid anyone actual cares about anything except themselves.  I'm hoping the movement towards ethical Capitalism, which there's a fair bit of support for even at the investor level these days, gains some momentum from cases like this.

For all of the people who are splitting hairs over whether code was copied or they just created compatible APIs, you're missing the point.

Sun invested hundreds of millions of dollars creating the Java platform and marketing it.  In doing so, it became well known to software developers who created a large ecosystem of server-side and mobile applications for it (not to mention having a ton of experience with it).  Andy Rubin and company come along with Android and realize that they need a good software development environment for it.  As stated in an email exchange between Tim Lindholm and Andy Rubin, they understood well that the only option was Java, but they simply didn't want to pay a licensing fee for it.  So they effectively cloned and owned Java by taking advantage of open-source projects at the time which had special licensing terms for Java.  Thus gaining all the benefits of the money invested in the Java platform by Sun within Android (which went on to help Google make a lot of money), but not paying a dime for it.

If you work in the software industry and somehow think it's cool that they found this loophole and exploited it, then I sincerely hope someone does the same to any products you happen to work on.  It's not right and I refuse to use Android because of it.  I love Linux, and have contributed to it over the years since it was my learning ground during my formative years as a software developer, but I won't touch Android.

And if you think that simply because Oracle bought Sun, it gives them a pass, it doesn't.

There was a previous article on here which linked to an overview of RCS and how different carriers have branded it with different names, with varying levels of support for different parts of the specification.  From a technical standpoint, it looked like a hot mess at this point.  Google is fine with that because they're not the ones providing technical support for Android-based phones.  They can live in lala land and implement it so that it works perfectly fine with other Android phones running the very latest version of Android on Wifi, and not have to worry about being inundated with support calls from confused customers when conditions aren't perfect: cellular connection from a carrier which doesn't fully support it, phones stuck on older (incompatible) versions of Android, other types of phones, etc.  Apple OTOH has to worry about providing tech support when an iPhone using RCS encounters less-than-ideal connectivity situations which are outside of their control.

KTR said:

Damn, and they pay the 30% App Store tax

And what a blow that must be.  Paying Apple 30% of $0 since the app is free and there aren't any in-app purchases afaict.

crowley said:

The article didn't mention it, but the costs are:

25 compute hours/month 
Free (through December 2023, then US$14.99 per month if you choose to subscribe at that time.)

100 compute hours/month
US$49.99/month 

250 compute hours/month
US$99.99/month 

1000 compute hours/month 
US$399.99/month

From: https://developer.apple.com/xcode-cloud/

I'm not sure why this is particularly useful unless it is substantially faster than on a local machine, and Apple don't seem to be making any claims about that.

It's really about the automation and maintenance side of things.  As a developer, I'm iterating and testing my app against the particular hardware configuration that I've set in Xcode.  However, to ship my app, I may need to build and test on 20 hardware configurations.  Sure I could set up a local Xcode server to run those 20 builds on each code change, but then I need to configure and maintain that server every time there's an Xcode or macOS update, deal with hardware upgrades, failures, etc.  Basically you're paying Apple to maintain a build server for you.

elijahg said:

MplsP said:

gatorguy said:

MplsP said:

How many of the people screaming about CSAM have Facebook, WhatsApp, Instagram, and google apps on their devices and an Amazon or google smart speaker in their home?

Implying Apple is not any worse than "everyone else" is not a ringing endorsement. 

xyzzy-xxx said:

MplsP said:

How many of the people screaming about CSAM have Facebook, WhatsApp, Instagram, and google apps on their devices and an Amazon or google smart speaker in their home?

I won't use a smart speaker, but regarding Facebook & co. you are comparing apples to oranges – just don't give these apps access to your photos etc. and think about what you are uploading and you will be fine.

my point was not comparing Apple to any of these other corporations. My point was that it's a bit hypocritical to be completely ok with all of these other 'services' snooping, scraping, monetizing and otherwise surveilling your personally life and then to start screaming about Apple trying to do something to protect the most vulnerable people in society in a way that preserves people's privacy.

Everyone makes the obligatory statement that they're against exploiting children, but somehow they're not willing to put their money where their mouth is. But they are willing to give up their privacy for the ability to brag about their vacation, post conspiracy theories and snoop on their neighbors. I find it a very sad commentary on people's values.

That's because people make a choice to use FB/IG/Twitter etc, they make a choice to lose privacy over the photo they post, and they are posting that photo to someone else's device. Plus, they agreed to scanning for "objectionable material" when they signed up. No service - not even Google or FB, scans the photos on your own device. Apple was going to install spyware on people's own devices without permission, and with no choice. No one agreed to Apple scanning devices for CSAM when they bought their phones. 

Ceasing to use FB/IG/Twitter doesn't cost a penny. Ceasing to use an iPhone could cost a lot of cash, especially if you are deeply invested in the ecosystem. 

You completely missed conveniently ignored the part where Apple wouldn't scan the photos unless they're uploaded to iCloud.  So it really wasn't a choice about not using an iPhone, it was a choice about not using iCloud to store your photos.  Same as the choice to not use other hosted services like FB/IG/Twitter.

Xed said:

entropys said:

Yes it should. Hardly anyone has USBc projectors. But they all have hdmi.

Is this really a problem, especially for anyone that has been using the latest Mac notebooks since 2016?

https://www.amazon.com/Thunderbolt-Compatible-MacBook-Samsung-Surface/dp/B07TLMZK6S/

It's truly incredible.  I've listened to so many people complain about needing dongles and adapters for Apple laptops over the past few years.  Now Apple creates a laptop which doesn't need them and people complain they shouldn't have done it.

For myself personally, I can't count the number of times where having an HDMI port on my 2015 MBP has come in handy.  Sure I'm doing work on it 90% of the time, and I always take adapters on work trips.  But often I take it on vacation with me and don't bother to pack adapters since I figure I don't need them.  Then I end up wanting to show photos & videos to friends/family and simply need to hook it up to the TV in their living room (as opposed to having to pass my phone around the room).  It's not a "pro" use case, but it's a "real life" use case.

OutdoorAppDeveloper said:

Here are two predictions based on this news:
1. Blender will render at around 1/10th the speed on the top end Mac Studio compared to a top end GPU.
2. Apple fans will blame Blender's developers because they don't know how to use Metal correctly.

Did you read the article?  Or are you just paid to post negative comments?

The addition of a Metal GPU backend, which was contributed by Apple

Apple themselves wrote the Metal backend for Blender.

Having actually written shaders in both GLSL and MSL, I can say that Metal is an absolute pleasure to work with by comparison (passing data from CPU to GPU is much easier).  The performance in my experience was about the same on equivalent GPU hardware, but then I wasn't writing a full blown 3D design application.  I'll be interested to see a comparison for Blender.