Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iPadOS

apple.com

Post reply on HN
Print view View original

171–180 of 393 posts

Re: iPadOS

#171

Post by Despegar »

privateSFacct wrote: post #83

Everytime I read about greenpeace talking about how Apple's products are so terrible for the environment while saying nothing about android products I roll my eyes. Same thing with the fix it folks saying Apple's products are "unrepairable". There is a great market for both repair and reuse / re-sale in apple products. It's interesting comparing a 4 year old android tablet or phone (which was sometimes a year behind…

iFixit and the other "right to repair" advocates are talking their own book. Apple products are uniformly the same across the entire installed base so it's easy to keep parts in stock and meet expected demand for repairs. They also have higher residual values so people are much wore willing to spend money on repairs for them.

Re: iPadOS

#172

Post by [deleted] »

nostromo wrote: post #55

I've tried to use these desktop-inspired features on iPad and they are befuddling. Using two apps at once is beyond confusing. A simple use case, like copying an address from a Safari tab into Gmail via split screen requires so many mysterious, undiscoverable gestures, I doubt almost anyone is doing that. I think Jobs was right that convergence between workstations and mobile devices requires too many sacrifices, at…

[deleted]

Re: iPadOS

#173

Post by jessriedel »

wlesieutre wrote: post #101
nostromo wrote: post #55

I've tried to use these desktop-inspired features on iPad and they are befuddling. Using two apps at once is beyond confusing. A simple use case, like copying an address from a Safari tab into Gmail via split screen requires so many mysterious, undiscoverable gestures, I doubt almost anyone is doing that. I think Jobs was right that convergence between workstations and mobile devices requires too many sacrifices, at…

A lot of discovery on desktop computers was by hovering over stuff for tooltips or poking around in menus. Touch devices don't have that, so you get the basic functionality exposed, but other stuff isn't as discoverable. I don't think this is as much of a problem as people make it out to be. They've managed to keep the iPad just as accessible to everyone, and they prod you occasionally with notifications from the Tip…

> Touch devices don't have that, so you get the basic functionality exposed, but other stuff isn't as discoverable. I don't think this is as much of a problem as people make it out to be. They've managed to keep the iPad just as accessible to everyone, and they prod you occasionally with notifications from the Tips app for people who are willing to learn more.

Indeed, I'd say the opposite: Most older folks simply do not discover stuff, or do so very rarely. They ask someone to show them how to do something, they memorize it, and they generalized/abstract from that only slightly. So they aren't missing the discoverability when changing to the tablet, while gaining a bit more intuition for swiping compared to the mouse.

Re: iPadOS

#174

Post by Abishek_Muthian »

Spivak wrote: post #143
tachion wrote: post #127

Earlier quoted context omitted.

How come? You can have Firefox and Chrome installed on iPad just as on iPhone?

Sorta, the actual browser chrome is provided by the 3rd party but the underlying rendering and JS engine are required to be the OS provided facilities (i.e. Safari) Apple’s security model is that Apple has to be able to inspect and review all the code you’re app is going to run. There is a special exception for JS provided that you run it though Apple’s interpreter. Browsers are caught in the crossfire of a much broa…

I agree, but apple has made an exception for coding apps to run arbitrary code for some years now.

So, it doesn't make any sense for Apple to not allow 3rd party browsers apart from its intention for a walled garden even if it means compromising security for its users.

Re: iPadOS

#175

Post by layoutIfNeeded »

whynaut wrote: post #151
nvrspyx wrote: post #107

Earlier quoted context omitted.

> you should never do this unless the app is unresponsive In theory, yes, but not in practice. For example, the chromecast icon sometimes disappears in Hulu, which requires killing the app and reopening to get it back. The stock Mail app used to get stuck in fetching mail and refused to refresh, again requiring you to kill the app. Facebook Messenger's text input sometimes disappears entirely, requiring you to kill t…

> In theory, yes, but not in practice. For example All of those are examples of unresponsiveness..

Nah.

Unresponsive = the app’s main event loop is not processing events. On macOS this is when the beach ball cursor is shown. In fact there’s a built-in watchdog in iOS that’ll kill your app after 10 seconds if the main thread is not processing events.

On the other hand an app can break in a variety of ways which won’t involve blocking the main thread, e.g. by simply opening a popup that can’t be closed, or getting stuck inside the wall in a game, etc.

Re: iPadOS

#176

Post by filoleg »

kodablah wrote: post #155

> QuickPath typing - Type by swiping from one letter to the next. Are there plans for this to be added for phone keyboards too? As one that appreciates it on Android, I imagine it'd be welcomed by many.

It already was added for phones in iOS 13 update last week.

Re: iPadOS

#177

Post by acdha »

Jyaif wrote: post #158
saagarjha wrote: post #124

Earlier quoted context omitted.

> In any case, I don't think there can be any opposing arguments on the side of security for Apple not updating Safari via AppStore or now allowing proper 3rd party browsers. Third party browsers entitled with dynamic codesigning poke a huge hole in Apple's security model for iOS devices.

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

Think about what a JIT compiler means: it's allocating memory, writing to it, and then executing it. That's also what malware does so if you give third parties access to that functionality you have the immediate problem that the number of people who can make a mistake which gives native code execution goes up dramatically and that any attempts to restrict it in the future will risk breaking previously-working apps — think about how many years Adobe was able to slack because nobody wanted to break Flash even though it was a huge source of security bugs affecting most people on the Internet.

Re: iPadOS

#178

Post by biztos »

prashnts wrote: post #19
radnor wrote: post #9

Earlier quoted context omitted.

You can connect quite a few things via the Camera Connection Kit (CCK) which has a USB port in it. MIDI controllers and USB soundcards are two things I've used recently.

Not sure what’s the CCK. Is it one of the dongles they sell with HDMI, SD Reader, and USB? I first got excited that it can connect to USB webcams — I have some modded webcams I use as microscope — would be super useful if I could interface it with a camera app. But it didn’t work, last I tried. Are you aware of some way to do that? :)

I believe they're talking about the "Lightning to USB 3 Camera Adapter."[0]. I have one of these and so far I have only used it to plug into my DAC[1] so I can use Apple Music on an old iPhone with a real HiFi, but I think this has been the preferred way to connect to multimedia stuff for a while.

A long time ago on an iPad now far far away, I had the cordless little SD card reader, but the iPad itself wasn't much use for editing RAW photos in that generation.

[0]: https://www.apple.com/shop/product/MK0W2/lightning-to-usb-3-...

[1]: https://www.schiit.com/products/fulla-1

Re: iPadOS

#179

Post by saagarjha »

rictic wrote: post #167
saagarjha wrote: post #124

Earlier quoted context omitted.

> In any case, I don't think there can be any opposing arguments on the side of security for Apple not updating Safari via AppStore or now allowing proper 3rd party browsers. Third party browsers entitled with dynamic codesigning poke a huge hole in Apple's security model for iOS devices.

Do you mean the ability to dynamically allocate executable memory? That's not necessary for shipping a browser engine (though performance would suffer, as that's how all modern JS VMs work, via jitting JS to machine code).

Yes. It's not necessary for a browser engine to do this, of course, but AFAIK the best interpreters can only approach or barely match simple templating JITs so you're probably not going to be able to write a competitive browser without this.

Re: iPadOS

#180

Post by Someone »

Jyaif wrote: post #158
saagarjha wrote: post #124

Earlier quoted context omitted.

> In any case, I don't think there can be any opposing arguments on the side of security for Apple not updating Safari via AppStore or now allowing proper 3rd party browsers. Third party browsers entitled with dynamic codesigning poke a huge hole in Apple's security model for iOS devices.

Can you explain why allowing apps to ship with a JIT compiler be a security issue?

A common attack method is to overwrite the stack or some buffer and then somehow make the CPU run the bytes written as code (https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation, https://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exp...)

A common mitigation to that is “write xor execute” (https://en.wikipedia.org/wiki/W%5EX)

From that page: ”Without such protection, a program can write (as data) CPU instructions in an area of memory intended for data and then arrange to run (as executable) those instructions. This can be dangerous if the writer of the memory is malicious.”

JIT compilers are collateral damage to that mitigation; they have to write bytes to memory and then make the CPU run those bytes as code, and W^X doesn’t allow that.

Post reply on HN