simscitizen

The easiest way to deal with this is to add your sender ID to the app manifest, so Parse registers with both its sender ID and yours:

https://parse.com/docs/android/guide#push-notifications-sett...

This requires a new release of your app, but that is a necessity in any case.

A version of this (called YellowSubmarine) ended up shipping in iTunes and Safari for Windows. You should be able to find a libobjc.dll, CoreFoundation.dll, etc. if you look around your filesystem.

> FWIW, I think Apple can't ship any base libraries that uses Swift until they finish ABI-compatibility

You hit the nail on the head here. Until the ABI is finalized, Apple can't ship dynamic libraries to developers that are written in Swift. Swift won't be ready to fully replace Obj-C until this happens.

Dynamic and compiled are not mutually exclusive. Objective-C is both a dynamic and compiled (to machine code) language that supports monkey patching. It supports extending classes with new methods and overriding existing methods in existing classes through its category feature.

This does have an unfortunate side effect though. Because Objective-C is a) compiled directly to machine code b) has no way of marking methods final and c) supports monkey patching, essentially no methods can be inlined by the compiler.

We wrote a tool like this in my last job to guess the width of raw images like these. First, we were dealing with iOS, and there are certain constraints on the platform which help with guessing width (bitmaps are generally 32-bit BGRA, and the rows in iOS bitmap images are aligned to 32 bytes). Because of the alignment constraint you only have to guess the width in 8-pixel increments. Then pick the width that minimizes the average pixel difference between adjacent rows in the image. This usually guessed the width of the original image (or an integer multiple of the actual width), at least when the original image was a UI element (as UI elements generally have large rectangular blocks of color in them).

The man behind Objective-C these days (and for the past decade plus) is this guy: http://www.sealiesoftware.com/blog/.

The packet tracer is an interface to a tcpdump-like facility that's used for debugging. It requires you to connect the device to a Mac host. The interface is publicly documented: https://developer.apple.com/library/Mac/qa/qa1176/_index.htm...

You can actually attach desktop Safari's Web Inspector to both Mobile Safari and webviews running on a remote iPhone and get debugging, console logging, etc. The native stuff still has much better tooling, but the situation with webviews isn't as dire as you imagine.

No you wouldn't. You'd only be screwed if you used that other copy of SQLite to open the SQLite file used by CoreData to store data. Which you shouldn't be doing anyway.

I was only considering the conflict between the system-provided SQLite and the private copy of SQLite in your binary, since that seemed to be what your article was about, and is the most common conflict. I hadn't actually considered that you would actually statically link two copies of the same version (or even different versions) of SQLite into your own binary and use those two different copies of SQLite to open connections to the same exact file.

In any case, don't have two different versions (by versions I mean copies) of SQLite open the same file in the same process. This is because os_unix.c does deferred closing of fds based on refcounting the number of open connections to the same path. With multiple libraries opening connections to the same path, the refcount for that path won't be correct in either copy of the library.

There is no problem unless you use different versions of the sqlite library to open connections to the same db file at the same time. This is because different versions of the sqlite library may use different locking strategies. But if you just want to use a different version of sqlite with your own sqlite files in your app's sandbox, then that's just fine. You may need to do some symbol munging since the system's sqlite symbols will clash with your copy's symbols.

One that doesn't seem to be mentioned: if you want to navigate to an absolute path using the keyboard from within a Finder window or a Save dialog, use ⌘⇧G to open a little "Go to..." panel that lets you type in a path. It has path completion and has tilde expansion.

iOS and OS X ship with Accelerate.framework, which include implementations of BLAS and LAPACK: https://developer.apple.com/library/mac/documentation/Accele...

The dynamic libraries in iOS aren't shipped as separate dylibs on the device. Rather, they're essentially concatenated together as part of a single file called the dyld shared cache that also lets Apple do some prebinding tricks, interning of objc selector names across all system libraries, etc.

The system-wide iOS build scripts actually randomize the order of the libraries in the shared cache by default (you can check this using dyld_shared_cache_util against the shared cache file, which you can compile from the dyld project on Apple's open source site). Since the ordering of dylibs in this giant shared cache file varies between builds, you could easily end up with a 15 MB diff even though all you've done is deleted a single goto in source code.

iTunes and other Apple software on Windows runs with code that looks pretty much exactly like that. Those code bases are compiled from Obj-C into plain C by the objc rewriter module in clang, then compiled into machine code by Visual Studio. You can take a look at what the clang rewriter does here: http://clang.llvm.org/doxygen/RewriteObjC_8cpp_source.html

Use sqlite3_open_v2 with the SQLITE_OPEN_READONLY flag. It's been there for several releases now.

One of the biggest impacts of moving to 64-bit is increased memory pressure. While all of Apple's apps and daemons are running 64-bit, most users will be actively using third party apps that are 32-bit-only for a while. This means that on average there is less memory available in the system, because the amount of RAM is unchanged in the 5s, and there will now be code from both 64-bit and 32-bit binaries resident, rather than just 32-bit binaries.

Apple has done some work to alleviate this extra memory pressure at the kernel level. grep for WKdm in the xnu sources if you're interested.

On OS X, use mach_absolute_time() to get a monotonic clock. A lot of APIs in OS X use the monotonic clock, e.g. CoreAnimation wraps mach_absolute_time() as CACurrentMediaTime() and uses that to calculate animation start times and delays.

If you set the drawsAsynchronously or acceleratesDrawing property on a CALayer (the former is public and the latter is private), then the CGContext passed to you in -[CALayer drawsInContext:] or -[UIView drawRect:] will be GPU-accelerated in the same way. WebKit on iOS uses this to accelerate 2D rendering.

Having said this, don't go turning this on everywhere, like on every tiny little UILabel. That GPU-accelerated CGContext is rendered in an offscreen pass using render-to-texture so it is often faster to use the CPU. This property was more designed for, say, a full-screen drawing app on a retina iPad that uses a a single screen-sized CGContext for its drawing canvas, or for the Safari case where there are a number of same-sized CGContext tiles to draw into.

There are plenty of built-in performance/introspection tools in OS X that you can try first before resorting to a third-party solution:

1) What ports it opens:

- netstat shows you what ports a program has running

- DTrace shows you all syscalls a process makes (among other things). dtruss is a convenient wrapper script included in OS X which shows you all the syscalls a process makes (including opening sockets.

2) What files it opens

- Again, DTrace's syscall provider lets you introspect all syscalls, including open(). There's even a handy wrapper script included with OS X called opensnoop.

- Alternately, you can use the fs_usage command line tool to tap into the xnu kernel's trace mechanism. This shows all sorts of filesystem events, including what files are opened.

3) What libraries a binary is linked to

OS X binaries use the Mach-O format, not ELF like most other Unixes. So you have to use OS X's binary introspection tools to understand that format rather than the standard GNU binutils. What you're looking for here is otool, which lets you introspect Mach-O binaries. Specifically, "otool -L /Applications/Mail.app/Mail" for instance shows you which libraries Mail links to. Run this recursively to get the transitive closure of all dependencies a binary links against. Another way to do this is to run "vmmap -v <pid>" to show you the vm layout of a process, which includes the __TEXT/__DATA segments of all libraries the process links against.

And of course, gdb/lldb is included with the developer tools, you can just attach to whatever process you care about and set breakpoints, type "info sharedlib" to see what libraries are in the address space, etc. Also, for better or worse, Objective-C is an extremely dynamic language, so you can even do things like write a shared library with code you want to inject into a process (potentially monkey-patching existing methods using ObjC categories) and dlopen it from gdb to insert it into the target process's address space.