or Connect
New Posts  All Forums:

Posts by plovell

It seems that third-party apps can use Apple Pay, but can't use NFC for something else. I would guess that this is because Apple doesn't yet have the API and SDK to the point where they want it publicly available. As well as just being cautious.
Aahhh - the return of dual-architecture binaries !! It's true that Xcode already deals with both. But while that is necessary, it is not sufficient. If Apple switches to ARM then a new Rosetta will be essential. Apple can either build one or license one from the current owners of the technology -- IBM. 
The point you've missed is that this is not supposed to be a revenue generator in and of itself. It's supposed to1. sell more iPhones2. be a competitive advantage against Samsung  For example, Samsung's fingerprint reader is enough for a feature checklist but every reviewer says that it's quite poor. Samsung can do some kind of "secure element" but it will take time and money, and who knows how really secure it will be? I do not see Apple Pay as a profit center. Apple...
There are two different things here and lots of folks are not noticing it.   One part is the standardization effort by those involved with GlobalPlatform. An example is the "tokenization" organized by EuroCard/MasterCard/Visa ("EMV") that Apple uses in Apple Pay. Other companies will be using this too. Maybe even Samsung :)   The second part is the TouchID and Secure Element, which are Apple-proprietary. Samsung has its own version but everyone who has reviewed it says...
The merchant gets some data from the transaction, but certainly not your credit card account number.  I would guess that, in your example of a return to Home Depot, you would still have your paper receipt that they can scan the way they do today. Or maybe with Apple Pay you would get a receipt on your phone that could be used  to bring up HD's transaction record. The issue of what number/token is used is an internal issue with Visa/MasterCard. Whatever it is, it links back...
I'm not sure of your question. It will compile source to either x86 or to ARM. But it won't convert, for example, x86 binary to ARM binary. Is that what you meant? But that's what Rosetta2 would be for :)
Xcode is easy. It already does both x86 and ARM. But getting major apps recompiled is insufficient. Just with the PPC -> x86 transition, this would need Rosetta. That was built by Transitive and licensed by Apple, but the company was acquired and the new owners did not want to renew the license. It's interesting that the new owner just happens to be IBM. With whom Apple recently made a deal. Very interesting indeed.
The terminal upgrade is ALREADY required, and under way. The driving force behind it is the switch to chip cards. After October 2015, any merchant still using swipe cards will be liable for fraud loss - not the bank. And these terminals will include NFC (many trade articles already confirm this). That does NOT mean that you will be able to use ApplePay at all of them - that requires agreements, and software in the merchant system. But the terminals will be capable of...
There's a difference between chip+PIN and paywave, and that is that paywave isn't authenticated (i.e. no PIN). So the transaction limit is lower. The advantage of chip cards is that the information on the chip can't be copied, as happens a lot with today's mag-stripe cards. And the paywave implementation in the U.S. is such that the card info can actually be read at a distance of about 3 feet (1 m.) with a sensitive antenna. That info can then go onto a mag stripe card and...
The current NFC usage is PIN-less and therefore has low limits. As far as we know, ApplePay is ALWAYS authenticated so I do not expect that the "pay wave" limits will be in effect. I can't believe that Apple would ever agree to such a limitation given the security in ApplePay.
New Posts  All Forums: