Hacker Newsnew | past | comments | ask | show | jobs | submit | ocrickard's commentslogin

Around the same time was the 64-bit requirement for app updates. This resulted in a dual-slice fat binary. Began being enforced in June 2015 I think, so about 2 years ago.


App Thinning handles that issue too.


It dies but store lists full fat binary size.


Here's to demystifying the internals of UITableView! Your tone seemed fine to me. Glad you geared it towards newer folks to iOS. I remember when I was first starting with iOS, one of the biggest questions I had on these things was "Why?". Luckily posts like this, and the treasure trove of Mike Ash's blog provide a clear understanding of both how the components in Cocoa work, and why they work that way.


Yeah, I was thinking the same thing. Loved that blog post, and certainly enjoyed looking at R. Nystrom's implementation too: https://github.com/rnystrom/RNTableView.

UITableView is one of those components that we all spend so much time with that everyone has little tweaks they want to make. Implementations like these at least give us options to extend/tweak low level behavior should we need to. I also love it when they write thorough blog posts like these explaining explicitly their rationale and structure of the component.


It's worth noting that they specifically state that for Gmail they can use OAuth through the refresh/access token system. Hopefully they do this for all other IMAP servers that support OAuth (there are a couple of them now).

However, for traditional IMAP/SMTP servers your point is well taken. They must store your credentials in a restorable state, which, however carefully you do, has difficult security implications.


It's a proxy. It doesn't need to store anything. The server asks for a password, the proxy asks the client.


In order to inject content into the stream, they must be able to decrypt and interpret the stream. It is not quite as simple as a traditional proxy which may not actually have to know the content it is transmitting. They must have all content you send over the stream for a short period of time in-memory in a restorable (if not plaintext) state in order to read from the client's IMAP stream, interpret, then send over the IMAP server's secure SSL stream. The short period of time over which they must keep it does not free them from the security implications. All an intruder must do is gain access, then monitor the stream. I'm not saying that this is impossible to mitigate, just that you're trusting them to do it right.


Awesome article. Very evenly balanced in its conclusions, though it avoided the subject of asynchronous rendering/layout. I would add that it is possible to achieve the 1/60th sec. setup time for more complex drawing (NSAttributedStrings, composited views) through the use of background rendering/compositing into CALayers that are delivered to the cells only when complete, though it gets complex very fast, and as noted the performance in newer devices is rapidly getting to the point that I don't have to think so much about this anymore. Now if only we could get everyone to drop the iPhone 4... (just kidding).


This man speaks the truth. Though I think the advice of "stick to the highest level API for your needs" holds true here as well.

(Hi oc, its Ryan!)


Hahaha, Hey Ryan. Totally agree. If you don't need to do this, DON'T.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: