HN user

bluk

158 karma
Posts0
Comments39
View on HN
No posts found.

The DMA did not mandate that they decouple their commission structure. That is Apple’s interpretation of the DMA which seems to change every few weeks so far. PWAs on home screens were disallowed and then allowed again. Apple looks like they do not have legal and execution discipline and is being caught flat footed. It is somewhat alarming that they have made so many mistakes (see Epic being revoked from their third party marketplace and then Apple being strong armed to re-allow because of a EU comment about investigation).

The idea that Apple is compliant with the DMA has yet to be tested. There are many direct statements by the enforcing commissioner and complaints from third parties that I think only a direct ruling will settle things.

I forgot about Prime Video purchases having a special back door deal for some of their purchases. I wasn’t referring to the subscription service but the purchase of digital books/movies. My point stands though. Digital goods could be sold and bought without special exceptions or loopholes from the 30% fee. That alone is a huge market opportunity.

I don't think so, at least not as a consequence from this case if Apple loses. Antitrust cases are usually very limited in scope. Microsoft's loss required many actions (documenting Active Directory and other protocols/formats, browser choice screens, etc.), but no one else in tech were required to do so.

John Sircacusa (from ATP.fm) pointed out years ago that the heart of Apple's biggest issues is business relationship management. This was when Apple only had a handful of issues with a few companies and made some poorly received statements about developers. Their ability to build mutually agreeable relations has only gotten worse in recent years.

Sony and Microsoft have kept their relations with third parties tough but ultimately agreeable. They promote practically all of their third parties (unlike the App Store which has so many apps that its like winning the lottery to be promoted). Consoles have stores which are probably more curated but which third party publishers/developers actually like.

IMO, DoJ, EU, etc. are acting primarily because they have received so many complaints from Spotify, Microsoft, Epic Games, Google, Meta, Tile, etc. Governments don't take action for the "public" interest on its own.

It is by no means unfair, immoral, or unethical for a company to prefer and promote their own products.

Unfairness is at the heart of so many antitrust lawsuits (whether successful or not). Anyone old enough to recall Microsoft in the 1990s would say that many people (not at MSFT) were pointing out how unfair bundling Internet Explorer was. You may disagree but it was one of the reasons MSFT got sued.

Cloud game streaming has been recently allowed worldwide under a few conditions ( https://developer.apple.com/news/?id=f1v8pyay ).

Forcing Apple to allow third party payments without Apple's cut would improve market opportunities for many businesses. Facebook could have its marketplace conduct peer to peer transactions. Amazon could allow the purchase of digital goods (books, movies, etc.) and put it on more equal footing with Apple itself. While big businesses are best positioned to take advantage today, the effects directly trickle down to small startup businesses.

While I personally don't care for it, cryptocurrency use would have more potential. Apple blocked apps for NFT features in the past because they couldn't get their 30%.

Having third party marketplaces might make it so that there is some actual curation at the App Store.

As much as I like Swift, the tooling has been and still is subpar. Swift package management is barely viable.

You have to use Xcode. You can try other IDEs but LSP equivalent features are at the most basic level. Xcode is the kitchen sink of IDEs which has led to many negative opinions as it struggles under its own weight. Every other year there’s new UI for things like debugging which is fine but what would be really nice is if the actual debugging worked. Technically there are reasons why you can’t print a local variable sometimes when stepping through a program, but in practice, I do not care and I want to know what the value is.

If you don’t care about the “optional” tooling like the dependency manager and LSP or a linter (which is closer to ESLint versus Rust Analyzer), the required tooling leaves much to be desired. The compiler sometimes gives up when it takes too much time to process a complex type. It would be understandable in some cases but most people encounter the problem when just writing seemingly simple SwiftUI. Error messages and auto fix-it suggestions are improving but still disappointing. I remember when Apple switched from GCC to LLVM and everyone was praising the error messages as a reason to switch.

Swift is actually ambitious. The generics system is world class. It has to support the legacy of a huge ecosystem on multiple platforms. SwiftUI is one of those bets that you might be surprised that Apple can still make. But whenever I fire up that SwiftUI Preview, I am crossing my fingers that maybe I’ll see something instead of an error. Swift lives up to its name in terms of moving quickly and the language design is probably fine, but outside of that, the tooling is still very immature for a decade old language which tons of resources are invested in.

Google Pixel Fold 3 years ago

I don't believe Apple has released empirical data, but Apple has optimized phone charging built into recent versions of iOS (Settings > Battery > Battery Health and Charging). It will stop at 80% and then resume charging to 100% about an hour before you start using your phone every day. iOS tracks your daily habits to determine the start of your day.

In the most recent iOS versions, if it can determine when "clean energy" is available near your location, it will also try to charge only during those time periods. I don't think any 3rd party has determined if it is effective.

Google Pixel Fold 3 years ago

Samsung, OnePlus, and other phone manufacturers have all been accused of throttling phones and have acknowledged the throttling and/or released patches to give more user control. You can google "<manfacturer name> throttling" and get new reports of throttling as recently as last year for Samsung.

Amongst others, probably referring to:

https://www.youtube.com/watch?v=p1nwLilQy64

and

https://www.cultofmac.com/125180/steve-jobs-was-originally-d...

Whether it's revisionist history or not, there were later claims that Steve Jobs knew they couldn't have a native platform ready when the iPhone was first announced so they stalled for time to a) get the App Store ready and b) see what types of app ideas were popular to get those platform APIs finalized. The interim solution was web apps with recommendations to look at the Dashboard APIs in Mac OS X (which were basically web apps).

I don't know if most people consider skeuomorphic designs obsolete/outdated, but the costs would be far greater today compared to when iOS was only for a handful of different resolutions for the iPhone and iPad. Not only do you have to consider the physical screen size differences with possibly different PPI, but all of the sidebar/split-screen/multi-window modes would require additional work.

It's kind of like when most websites started to switch to responsive designs where image heavy layouts and other fun animations kinda dropped off. It was just too costly to make things work well.

I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely.

If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).

FWIW, for the process_item function, I've found writing it like:

  struct Item {
      value: u32,
  }

  fn process_item(input: Option<Item>) -> Option<Item> {
      input.map(|mut item| {
          item.value += 3;
          item
      })
  }
to be more "idiomatic" instead of doing the match on the Option. The methods like "unwrap_or...()", "map...()", "ok...()", "and_then()", etc. on Result/Option are very useful, if not a bit difficult to find the right one to use sometimes. Deeply nested match, "if let Some", etc. code becomes like a straight chain of method calls. In the end, I find that the Result/Option methods shorten code considerably and improve readability.

Also, instead of doing an unwrap() on optional values for assertion, sometimes I like:

  let my_list = vec![1,2,3]; 
  assert_eq!(Some(&my_list[0]), my_list.first());
Mostly just depends though since I don't care too much in tests.

I agree that it was ridiculous and to be on guard for these shenanigans. 100%.

Today though, BMW is not charging a “subscription” fee and much more importantly, all of their iDrive data is provided for free with free software updates. And yes, competitive pressure probably forced them to, but it is much better than just 5 or 6 years ago where you were charged for yearly map updates by buying a DVD. They are also the first car manufacturer to support the CarKey feature so they have changed (for now anyways).

HomePod Mini 6 years ago

If you're going for the HomePod (vs. the HomePod mini), buy it only if you have Apple Music or iTunes Match. It's really not worth it otherwise. I have a Google Home, Google Home mini, and an Echo Dot (got all of them for free except the HomePods).

Assistant wise, you'd get better results from Google Assistant/Alexa. Apple has been lagging and playing catchup (from not having multiple timers in the initial HomePod release to adding voice recognition last year when Google had it earlier). The answers are more limited like your iOS Siri (don't expect anything better). Even worse, it seems like HomePod's Siri backend is different than say an iPad's which generally means it's a generation behind. For instance, the HomePod doesn't really support continuous conversations/follow-up questions.

Siri is ok finding popular music, but if you ask it to play the "The A-List: K-Pop playlist" vs. "The A-List: Pop Music" for instance, it's a tossup on which it chooses dependent on the alignment of the planets. The same goes for musician names where if it kinda sounds like the more popular musician, it will tend to choose the more popular one. Furthermore, if you have a specific version of a song (say acoustic/live version), then the HomePod always tends to pick the most popular version of the song even if you say "acoustic" or any other hints.

There are "Shortcuts" on the HomePod. You can use it to add Todos to third party apps (if you don't want to use the Apple Reminders integration) or play a podcast from a third party player from your iPhone/iPad. Not as useful as Alexa skills and every now and then it takes some magical phrase to correctly activate them. The main problem with Siri beyond lacking knowledge is that Siri lacks consistency. While it's ambitious in letting you say anything versus the narrower "scripted keywords" that Alexa understands, if you say something one day that it perfectly understands and repeated it exactly a week later, you have no idea if Siri will still understand you. I read about this complaint before against Siri, but having experienced it more than a few times now, it is incredibly frustrating. And Siri sometimes (unintentionally) mocks you by repeating all the main parts of your request back to you correctly, but it does the wrong thing.

Hardware wise, the HomePod sounds better than a Google Home, Google Home mini, and Echo Dot. But of course, the others are cheaper. Two HomePods do sound better than one. Besides the better output, the mics are significantly more sensitive even in a loud environment. If you're putting the HomePod in a noisy kitchen or playing music loudly, then a HomePod can pick up your voice without you shouting at it.

The Apple TV integration has gotten better, but even with two HomePods, a relatively cheap home theater setup sounds better and can be used for all your TV content instead of just from your Apple devices. If you place the HomePods right next to the TV at roughly the same height, they sound good but if you move them too low/high or around the room, it does sound "off". The whole spatial two HomePod thing kinda does work for music in a room, but for TV content, it does not.

Really the other assistants are as good if not better than the HomePod, then the only distinguishing (non-privacy) feature is if you want a premium and pretty good way to listen to Apple Music. Maybe a few more music services which hopefully will be available soon. I don't regret buying the HomePods at all because I do like listening to music on them, but all of the assistant and "smart" tech is available on your iPhone if it can hear you.

https://www.cars.com/articles/wireless-apple-carplay-and-and... lists 2019 model cars with Wireless CarPlay. I've driven one and tried out the wireless CarPlay, and it works more or less like the wired version (no lag, as smooth as wired CarPlay AFAICT). The only major inconvenience is probably that, if you have a passenger and they want to use their phone for music, you will need to pair their phone to the car instead of just finding the wire and plugging in. Takes about 30 seconds to a minute to go through all the setup. While the cars listed are not cheap by any means, there are a few moderately optioned minivans around the same cost of some of the less expensive cars from BMW (base cost around $38K USD).

Honda is also rumored to be adding wireless support ( https://appleinsider.com/articles/20/10/10/wireless-carplay-... ) for their 2021 Accord model so seems the feature is become available on more affordable cars too.

Having worked at a payment processor, if you are a medium to large business, you can cut deals with payment processors for a much lower fee. They are very competitive, and of course, Apple would be a special customer given very generous terms (assuming Apple are not processing the transactions themselves which is possible). This does not even take into account Apple store credit via gift cards and the like or purchasing different apps in one transaction which eliminates or lowers the fees.

I don't know if you tried reading The Swift Programming Language book ( https://docs.swift.org/swift-book/LanguageGuide/TheBasics.ht... ). It's a fairly quick read and has brief explanations with simple examples. You can skip some sections if you have prior programming experience, but if you're confused about Swift's function arguments, you may want to skim even the basics since a few things like control flow (e.g. the switch statement) are unique compared to C/C++/Java/C#.

The key quote in the Verge article is:

"Carolyn Wang, communications lead for Verily, told The Verge that the “triage website” was initially only going to be made available to health care workers instead of the general public. Now that it has been announced the way it was, however, anybody will be able to visit it, she said. But the tool will only be able to direct people to “pilot sites” for testing in the Bay Area, though Wang says Verily hopes to expand it beyond California “over time.”"

From https://www.theverge.com/2020/3/13/21179118/google-coronavir...

From this quote and the behavior of Google's communications team (whether Google or Verily), you can assume that Google/Verily were caught off guard by the announcement of Google's involvement. Whether it was Google's original intent or not, it seems Google is trying to make the best of the situation now.

I think another way to view this is, while Swift could be performant, but idiomatic code in practically any other language may be utterly wrong in Swift.

For instance recently this nested data structure "issue" was brought up (again) in the Swift community: https://mjtsai.com/blog/2019/11/02/efficiently-mutating-nest...

If you had a nested set in a dictionary:

``` var many_sets: [String:Set<Int>] = ... let tmp_set = many_sets["a"] tmp_set.insert(1) many_sets["a"] = tmp_set ```

vs.

``` var many_sets: [String:Set<Int>] = ... many_sets["a"].insert(1) ```

The performance is entirely different (e.g. you are making a copy of the Set in the first example). Prior to Swift 5, you would have had to potentially remove the set from the dictionary in order to make sure there were no unintentional copies.

While the examples are contrived to some degree, I think at least a few new Swift programmers would lookup something in a dictionary, pass the value into a function thinking it's a reference, and then when they realize it isn't being changed in the dictionary, set the value in the dictionary after the function returns like:

``` var many_sets: [String:Set<Int>] = ... let changed_set = process(set: many_sets["a"]) many_sets["a"] = changed_set ```

It is "easy" to understand what is happening when you know Swift's collections are value types and about copy on write and value vs reference semantics, but it is also an easy performance issue.

Furthermore, when web framework benchmarks like: https://www.techempower.com/benchmarks/#section=data-r18&hw=... show Java's Netty vs. Swift NIO (which is based on the architecture of Netty), I think that it indicates that you cannot just port code and expect anywhere near the same performance in Swift.

Swift Numerics 7 years ago

I've pushed a few admittedly minor backend services in Swift to production. It is ok.

You basically have one viable non-Apple OS platform (Ubuntu) to deploy on. This means that your basic Golang service is a 10MB Docker image while it can be over 100MB for a basic Swift service. There are frameworks like Swift NIO which is based on Java's Netty (and there are some Apple developers who work on Netty also working on Swift NIO). It works well enough but in most benchmarks, Swift is not even close to Netty ( https://www.techempower.com/benchmarks/#section=data-r18&hw=... ), so if you're pushing the code expecting high performance, I would think twice. Swift gRPC (latest version based on Swift NIO) is also available, and while I think it works very well, it is still relatively new.

As far as tooling, Swift is very immature IMO if you step outside Xcode. There are efforts to get a LSP service fully working (SourceKit-LSP), but I find it to be ok at best (performance and code completion suggestions are often very hit or miss). From benchmarking to diagnostics/backtraces to logging and metrics frameworks to shared common knowledge/answers on Stack Overflow, it is still very early days for Swift. Golang is so far ahead here that I personally think (at least today) the only reason you should launch a Swift service into production is because you want to reuse code that you have in your app.

If you like Swift's type system and want a backend service equivalent, I would strongly recommend looking into Rust. IMO, Rust is a version of Swift where the programmer is given more control of what the code is actually doing (along with the associated responsibility). It sounds like a lot of trouble, but I find most Swift code naturally translates to Rust code (especially if you follow the "value vs reference" semantics ideology that the Swift compiler team advocates). At worst, if you learn Rust, you will understand Swift a lot better (like what really is an escaping vs. non-escaping closure or what is the difference if I use a generic versus a dynamic protocol type (dyn trait in Rust) in a function definition).

Related to this, I wish more of Hulu's financials were made public. They have essentially concentrated on growing their ad-supported subscriptions by cutting the consumer price and doing subscription bundle deals with others like Spotify. Sometimes you could get Hulu for $1 per month (when it costs about ~$12 per month for an ad-free subscription).

Is it due to ad supported subscriptions being worth more to Hulu or is it just a subscription count growth strategy?