The error message "Invalid value around line 1, column 0." is consistent with having invalid bytes at the very start of the file. Maybe there are some non-printing (invisible) characters there for some reason? (I initially thought byte order mark, but that seems to work fine.) Try examining the file directly via this command: $ hexdump -C <path-to-your-JSON-file> | head -1 The expected output is exactly this: 00000000  5b 7b 0a 20 20 20 20 22  4e 61 6d 65 22 3a 22 49  |[{.    "Name":"I| If the first character isn’t the opening square bracket, that’s bad. Let us know what it shows.

That’s the correct and documented behavior: the kilobytes and megabytes units are powers of 10. For powers of 2, use kibibytes and mebibytes.

Is the goal to make your custom cell type (packaged in a library) acquire custom design-time behaviors like UIKit cell types when placed in a storyboard? That is, there would be a content view already present inside your main cell view in the storyboard? Unfortunately this sort of customization isn’t supported. The user can put your cell type into a storyboard (by dragging in a regular UIView and then changing the class name) but it will always just be a plain UIView as far as Xcode is concerned. You can let the user customize your cell in certain well-known ways of course, such as by IBOutlet (maybe require the user to install their own content view and hook it up to an outlet named contentView), and you can expose extra properties via IBInspectable or IBDesignable. By “implement it all yourself” I meant that at run time you could add behavior such as re-parenting all the user’s direct subviews into a custom content view that you create, setting up constraints to achieve a desired layout style, etc.

Is there any markup or protocol, that instructs Xcode to add views to view's "contentView" as it does for cells? Plain old views don’t have a concept of a content view. If you want to achieve a design similar to table cells or collection view cells, then you need to implement it all yourself.

The missing files are found in a couple of Git submodules which don’t seem to get cloned if you use GitHub’s Open with Xcode or Download ZIP options, or a normal git clone command. It works if you use git clone --recursive like this: $ git clone --recursive git@github.com:macmade/QEMU-Manager.git

Also check out session video Understanding Undefined Behavior from WWDC17.

Off-by-one error: the 3rd argument to mergeSort needs to be the index of the last array element, not the array size. So you are actually sorting 14 elements including the garbage value past the end of the array, rather than 13 elements. The varying output depends on whether that garbage value sorts into the first 13 elements or not. If it always “works” on Windows then the stack may be pre-filled with a debug byte value that is always greater than 7, rather than random bytes seen on the Mac.

It’s actually a good idea. Using dots is sort of a legacy format that still works, except in the case of Xcode 13’s new automatic build number management feature. That feature assumes CFBundleVersion is a simple integer and quietly truncates starting at the first dot. That’s what happened in your previous question. Consider CFBundleVersion as an internal build number. It doesn’t have to resemble your user-visible CFBundleShortVersionString in any way. You can reset it to (say) 1 every time you bump your CFBundleShortVersionString. And if you adopt the automatic build number feature, then you can just leave it alone and let Xcode bump it for you when uploading. Also consider the current documentation for CFBundleVersion to be obsolete. Someone should submit a feedback on that.

Bump! This is still broken in Xcode 13.2.1 (13C100). In case anyone else wants to help out by entering a duplicate feedback report. (I’ve already migrated a number of existing projects to auto-generate Info.plist, which is a nice little cleanup. But migrating my last project is blocked due to this bug. Bummer.)

In general, don’t assume anything that isn’t guaranteed in the documentation. It would be perfectly legal for the next OS release to cap the read chunk at a maximum of (say) 42 bytes. If this would break your app logic, then you should program defensively to handle it.

It’s something to make certain of us feel old. Or more specifically, “curses is a terminal control library for Unix-like systems, enabling the construction of text user interface (TUI) applications.” I recall trying to make a Hello World type of app using curses on my school’s state-of-the-art green-screen Zenith terminals around 1989, but didn’t yet have the C language skill to make much progress.

Try deleting the file right after you call resume() on the task.

The atob() function is part of the window object in browser JavaScript, but there is no window object when using JSContext directly. One solution would be to implement the functionality in native code (Swift or Objective-C) and call it from JavaScript. See JSExport (link) and various online tutorials.

Adding a little to Deepa Pai’s correct answer, your bundle version got “incremented” to 302 because the new auto-managed version logic seems to consider only the first part of a dotted version string. So it considered both your old 301.3.12010 and your new 301.3.13061 to be equivalent to simply 301, therefore duplicate, so it incremented to produce 302.

There is no documented API for any of that functionality. That would go way, way, way outside your app sandbox. It seems that 3rd party app management is a thing on Android, but it’s not a thing on iOS.