Yeah I experienced this yesterday and it was really cool. It really only happened once though.

I made an account there to use my Home Assistant as a media server and it's already the second time they reported that they messed up something. I heard you can install VLC on the Apple TV and stream through that, so I'll definitely do that and skip these weird middle companies.

Why not use Jellyfin then? It's basically an open source alternative to Plex. You run Jellyfin on your server and in Apple TV use Swiftin (Jellyfin + Swift) for integration.

I just use infuse or vid hub app and an SMB share.

I think Swift Concurrency is a great idea that unfortunately wasn't executed very well. The motivation behind it is that concurrency is difficult to understand and tricky to get right, but Swift Concurrency is at times even more difficult to understand and has even more pitfalls and gotchas compared to old-school synchronization primitives. I don't know where exactly it went wrong but it does feel that they really overcomplicated this feature.

The most hilarious yet infuriating thing for me is when you point out a mistake, get a "You're absolutely right!" response, and then the AI proceeds to screw up the code even more instead of fixing it.

You can have aliases on Gmail if you use Google Workspace (for custom domains), but there's a limit and no support for wildcards. Wish they had those, because then it's very easy to find out who sold your data

You can easily set up a catchall that goes to a group by modifying the default routing rules.

If your workspace domain has multiple users with non-overlapping responsibilities, that isn't very useful.

Aren't credit cards nowadays basically physical private keys? IIRC transactions are one-time payloads signed specifically for that operations, so intercepting that won't help you if I'm not mistaken about how cards work nowadays.

Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance. And maybe even send the money to a different account.

Sending money to an arbitrary different account isn’t going to happen from the terminal reader itself.

Banks don’t have wide open protocols where anyone can submit a credit card transaction and have it go to arbitrary accounts.

Remember that credit card companies eat the cost of the fraudulent charges. They’re not going to make it easy for those to occur.

Credit card companies eat the cost of fraudulent charges that they can not pass on to/blame the merchant for.

Which is why they won’t have a public API that allows running transactions that send money to arbitrary accounts.

If someone altered the terminal to charge more (a hypothetical suggestion above), they could recoup that money from the merchant’s account because they have an agreement in place.

You can’t run arbitrary transactions to arbitrary accounts (the other proposed attack above) because there isn’t an agreement in place.

Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.

> Yeah, I did think of that. I've never played with one of those so I don't really have much of an imagination about what they could do with a cracked one.

I've got a couple on my desk right now; there's nothing I can do with them to steal money, even though they're in dev-mode.

Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.

> Someone in a parent post mentioned that you could change the merchant entirely, thus syphoning off the money to a potentially more accessible account.

That would be something I'd like to see. The terminals I have worked on do not store merchant details. A merchant ID is stored on the terminal, with the ID mapping to an actual merchant account on the backend.

In order to have the merchant account on the backend, you need to be a customer of that terminal supplier. If you are a customer, they know:

a) Where your terminals are deployed

b) Your real details

c) The terminal's ID and the terminal's serial that maps to that specific merchant ID.

So, let's say we do change the merchant ID from `12` to `24` on the terminal. The request goes up with `transaction(<amt>, 24, 'sr-12345')`, and then the backend rejects because terminal sr-12345 is not mapped to merchant 24.

Lets say we also manage to fake the serial number. Then the transaction is approved, but can be easily reversed because merchant 24 is a customer and we have:

1. Their bank account number 2. Their physical address 3. The company registration number 4. Verified ID copies of the owner, directors, managers, etc. 5. Their money (from their transactions).

So, yeah, I'd love to know more about how they execute this hack; it would require complicity on the backend to a large degree.

3.

Yeah, ideally you'd need a valid merchant id, pos id and a way to siphon from the other merchant.

Probably not worth the small amounts you could make before caught

Arbitrary account, no. An arbitrary merchant, yes.

That typically doesn't even need root access though but only a numeric PIN. Of course rout access might let you conceal what you are doing better.

You should read up on the wonderful system they call ACH.

> Kind of, but if you control the card reader you could charge more for the transaction without showing the amount, for instance.

Not supposed to be possible on a certified terminal. The certification tests this particular case (the transaction is a hash of the keys, amount and a few other things. The display of the swipe/tap/insert screen and the pin-entry are under control of the certified kernel, so the userspacve application has no control of the amount that is displayed).

> And maybe even send the money to a different account.

Not from the card reader.

I've heard of it happening here in Brazil. In the simplest variant, something is glued on top of the screen to hide the higher digits, making the value appear to be lower; supposedly, some more advanced variants of the scam have a damaged or tampered screen.

I was victim on this attack in Argentina. Paid a taxi with my card, and got charged 50x the amount shown on the display.

unless it's changed recently that only applies to tap and chip payments (which you should always prefer to avoid card skimmers) and not the old slide the ~~barcode~~ magnetic strip kinda payment.

Does anyone still use the magnetic strip? I think it's been over a decade since I've seen a credit card without the chip, and terminals have been able to read the chip since forever. I think the last few times a store tried to use the magnetic strip on my card (because the chip failed to read due to a bad contact), the transaction was simply rejected due to not using the chip.

Yes, occasionally when refueling a shared car owned by a company that distributes those cars all over The Netherlands. It's common here in leased car fleets as well, where the user gets a magstripe card to refuel (and needs to provide details about current mileage and if the car was a replacement car).

I used it recently because my bank denied the contactless and chip payments I tried before that. Surprisingly the mag stripe worked - and this is with card issues from a EU bank where mag stripes have been an historical artifact much longer than in the US.

2 times just this week I was asked to swipe, “issues with the chip reader” (CVS and Wegmans)

USA was very late to adopt chip/tap terminals, even relative to Canada. I could be wrong but IIRC it was only when Apple Pay came along that tap-enabled terminals began to hit critical mass.

It's always incredible to see few people in the US uses the tech that's available until Apple makes it a thing, and seeing that play out over and over.

This is the same everywhere though. See, e.g. incredibly late fibre rollout in many well off EU countries because they already had copper in the ground everywhere vs. developing countries that never had that legacy infrastructure inertia.

What I'm talking about is a lot of those terminals supported tap to pay well before Apple Pay became a thing. The infrastructure was there, the technology was there, you could use it if you cared to do so. Most people just didn't know it was even an option. Google Wallet supported tap to pay years before Apple Pay was even announced. Tap to pay credit cards existed years before then. Nobody gave a shit about the technology until Apple announced Apple Pay and suddenly it became a big deal for vendors to actually check if their POS systems had it enabled or not.

I remember using Google Wallet years before Apple pay existed. When Apple Pay was announced so many cashiers thought they didn't support tap to pay credit card transactions despite me using it at those locations for years. What was really annoying was a lot of vendors turned off the feature while they "investigated" supporting Apple Pay, and didn't turn it back on for another year or so after they slapped the Apple Pay logo on the exact same terminals.

Nobody cared until Apple did it.

Seems surprising to me. I've not swiped a UK card in many years. Honestly can't remember the last time.

It's curious you're seeing so many stripe fallback incidents. Is this a USA issue?

possibly, can’t recall having any issues in europe where I reside over the summer.

That's wild to me, the last time I had to swipe my card here in Australia was sometime in the early 2010s!

Heck a lot of the terminals here can't swipe a card at all

In the USA, gas station pay-at-the-pump were the last major holdouts, but it’s been a while since I saw a pump that didn’t use chip or tap to pay.

My HSA debit card, issued last year, still doesn’t have a chip.

Old automatic vending machines and old municipal parking meters still require swipes.

In some regions, credit/debit cards no longer have magnetic strips.

If I travel to the USA I'll be unable to use these old vending machines and parking meters.

> unless it's changed recently

In Europe it's changed 15-20 years ago, when EMV-capable terminals became required, and acceptance of magnetic stripe cards got phased out soon after.

Since Apple Pay became a thing a decade ago, we don't even get US tourists confused by inability to swipe their cards anymore.

Note that is for the merchant side, not for the customer side - my EU-issued card still has a working mag stripe (got a chance to verify that it works this year).

And on a tangent about confused customers - I wish where to tap was as obvious as where to swipe. It varies by reader and sometimes that contactless logo is hard to see.

Not to mention the (usually mobile) terminal designs where only the merchant sees the amount entered, usually doesn't flip it to show it to the customer, and the customer needs to tap it on their side without first seeing the amount entered.

... such as this one: https://www.paxtechnology.com/a77

“which you should always prefer to avoid card skimmers” could use a disambiguation comma between “prefer” and “to”; I misread it several times before the intended meaning clicked.

I think you are mixing some different concepts here. It's not that this is a layer on top of Xcode/xcodebuild, it's just that Apple today happens to package everything iOS/Swift-related together with Xcode releases. So even if you couldn't care less about the Xcode IDE itself or the xcodebuild build system, you still need to have it because this is the only way for you to download / install those toolchains. Apple could provide these separately, but they just don't.

xtool creator here, this is correct. it wouldn’t have been possible to support Linux if xtool was just a layer on top of Xcode, as Xcode doesn’t run on Linux.

we only need Xcode to be installed on macOS since it bundles the iOS SDK (ie all the header files.) similarly, we ask the user to supply a copy of Xcode.xip during the setup process on Linux in order to extract the SDK.

it definitely depends on your definition of “replacement” in the end, but I (and most people I’ve spoken with in the iOS community) would consider “Xcode” to be the Xcode build system, user interface, and proprietary tooling. xtool doesn’t rely on any of this, not even for signing and installation. you can (read: must on Linux, may on macOS) use it with the open-source Swift and Clang toolchain + LLVM’s LLD linker and MachO tooling. Codesigning uses zsign, an MIT-licensed x-platform codesign alternative, and installation relies on the open source libimobiledevice project, which is installed by default on many Linux distributions (eg Ubuntu).

I've been developing a fairly popular macOS app for years. I consider myself in the community for that reason.

Apple has bundled everything together in a big mess.

- Only certain macOS versions can run certain XCode versions

- Only certain XCode versions contain certain SDK versions

- XCode embeds "Command line tools" which contains things like gcc, ruby, python, installed as a package, and conflicting with other versions on the machine

- Interface Builder is built into XCode and has its own compatibility story

It's a big messy blob and you can't pick-and-choose parts. You have to update your whole machine to move to the latest OS so they will let you run the latest XCode, so your app can compile on the latest platform for your users. It's not the best experience for sure. Many ecosystems have SDKs that you can download as you wish. I don't need to update my OS to download a version of the JDK for example.

That being all said, if you require users to download XCode, regardless of which part of it is necessary, i don't think you should mention "XCode free experience" or "XCode replacement".

I'm already developing a macOS app without launching the XCode GUI. I use the xcodebuild CLI that ships with XCode. My IDE is AppCode. I also use xcodebuild on CI to build the app headless. I would never call that a XCode free experience though, as i suffer from all the issues i mentionned above with version upgrades and XCode issues

I'm not too familiar with the xcode dev environment; could Theos be used instead of the huge xcode bundle? As far as I know, it provides the compilers and frameworks directly.

I’m also one of the maintainers of Theos :)

When you use Theos outside macOS, you have to install a toolchain and SDK. The toolchain is built from LLVM + cctools, and is in fact very similar to the one we use in xtool (I maintain both.) The SDK is hosted on GitHub and I could’ve decided to use this instead of getting the user to supply a copy of Xcode, but the copyright status is iffy; there’s an argument to be made in light of Google v. Oracle but I didn’t want to take any chances.

That makes sense, thanks!

I'm excited for the possibility of this being integrated with multiplatform frameworks like KMP. I wouldn't need to boot up my hackintosh anymore :)

Would it be possible to get just the SDK from the Xcode package? Like Asahi installer streams only the relevant parts of macOS images from Apple’s servers.

I looked into streaming but afaict the XIP format doesn’t support random access the same way that ZIP does. specifically because 1) it doesn’t seem to have a Central Directory like ZIP and 2) it has an optimization where files can be hardlinks to other files (by ID) in the XIP, so if you want to extract a file but all you get is a hardlink ID, you can’t expand the contents until you encounter and expand the hardlink pointee. it’s possible I’ve missed something, open to ideas for sure.

I do have an idea that will add a lot of complexity for sure: you can extract Xcode, mapping out whick portions of the archive correspond to the SDKs we need, then use this mapping to only download these relevant parts, reconstruct the archive and expand it. Not sure if it’s worth it!

There are some components that may be downloadable separately but they really are part of Xcode. One ring to rule them all.

It sounds like this "cross-platform xcode replacement" isn't cross-platform, and ios app developers still need macos?

But that's wrong. You don't need macOS. That's why they say "cross-platform Xcode replacement". You just need the SDK, which can be used on every platform.

IIRC, you need to run on Apple hardware for a valid SDK license. VM or Asahi or Hackintosh would suffice, but not a VM on a random Linux box. Or did the terms change lately?

Thank you. I did not make it clear enough that I was asking for clarification there.

Agree on Paul Hudson being great, but not so much on the guiding around the pitfalls. One big issue with the Swift community in general in my opinion is that a lot of the community content is incredibly shallow. Most of them are fine with "there's this feature and you can do X with it, cool right?" style-content, meaning very few people actually take the time to explain what the trade-offs are / performance considerations / how things work under the hood, and IMO this took a huge negative hit in the average skill level of Swift developers.

I think one of the problems is that the people who are actually using the language features generally don't have time to do it, Apple doesn't do it themselves, and Paul Hudson has 300 new features a year to view. Plus, iOS developers cargo cult harder than any other programming community I've come across, and this generally doesn't work really well if your explanation is difficult to quickly convey.

Setting up a Pi-Hole taught me a ton about how networks work. It's a really cool thing to setup for fun.

I find Cursor (or any LLM in general) to be amazing at doing very simple and concrete tasks for me. It really saves me a lot of time.

But the keyword here is "simple and concrete". I do not understand why people expect those tools to be good at tasks that involve having years of context on something. It really makes you think that the people that say that AI will replace SWEs have never actually used any of these tools.

Yes. I've loved not having to do some of the boring busywork tasks of coding. Basic CRUD pages, simple frontend stuff, general glue between existing services.