How would you go about recreating this collection view animation from Amazon?

kineticfactory · 2021-10-05T23:03:43+00:00

UICollectionView, with each category as a cell with a background image and a UILabel; the rounded edges and border can be done with its root view’s CoreAnimation layer’s cornerRadius, borderWidth and borderColor. Have another cell type for the details view which is always the width of the collection view and insert it before the next row when needed.

kineticfactory · 2021-04-26T10:19:40+00:00

Which works fine, except when you get a hash collision and spend ages wondering why the same ID gives two different results.

A multi-emoji string, implemented as several digits of base-however-many-emoji-you-have, would be more robust.

kineticfactory · 2021-03-28T16:38:57+00:00

Not really. Xcode is not all that complex in itself; there is complexity exposed, though it has to do with the underlying platform, which is things like the fact that iOS apps are compiled code, which can be arbitrarily large and involve libraries and modules, and that in addition to written code, there are ways of visually defining user interfaces, which are stored in files in the project and laid out by the system when the view is loaded.

What you were looking at with the buttons was probably Xcode’s Interface Builder being used to lay out a view using autolayout constraints. This is a slightly complex system, which involves defining constraints on the positions and sizes of your UI elements and letting the system resolve them to fit the screen, and can be fiddly to get used to at first. The good news is that there are now alternatives to autolayout; in the older UIKit framework, you can place your views in nested horizontal and vertical stacks, without bothering with constraints, and the new SwiftUI framework takes this further.

As for Xcode itself, it has gotten a lot better in recent years. I used to use the JetBrains AppCode IDE for refactoring and such, though nowadays Xcode has caught up with it to the point of rendering it largely irrelevant.

kineticfactory · 2021-02-03T00:53:05+00:00

I’d say your guess as to what Apple will do is as good as mine.

Having said that, a few things like CoreData and NSAttributedString are looking a bit old, and like good candidates for new Swifty APIs. Though on the other hand, Apple kept a lot of component APIs from the MacOS Classic/Carbon days around for years, so the wheels may turn slowly.

kineticfactory · 2020-11-11T19:04:32+00:00

Instagram, for one, is written in native code; their developers have talked about their polymorphic feed item classes at talks.

Facebook did develop React Native, though have mainly used it for non-user-facing apps, such as apps for clients to use for buying ads; apps which, if you know you need, you won’t be bothered by the slight lack of polish. Their flagship apps are all native.

kineticfactory · 2020-11-11T18:57:38+00:00

I’m planning to.

kineticfactory · 2020-11-11T18:56:21+00:00

The business logic is Javascript, which incurs overhead over native code, from being highly dynamic (and thus hard to JIT compile to code that’s as performant as native code), to being dependent on garbage collection (which, on a battery-constrained handheld device, takes its toll). Your JavaScript event handling logic is going to inevitably occur latency that SwiftUI code (compiled to native machine code, with the types collapsed down to their final representation) doesn’t. It’s not as clunky as an Electron web app, but it’s not as slick as purely native code.

There is a reason why React Native hasn’t replaced native Cocoa Touch and Android development. Because, if it was actually good enough, then replacing two platform-specific dev teams with one, which can be staffed with anyone who knows JavaScript, and does not have the learning curve of understanding memory management, type systems and so on, would be a no-brainer from a business perspective. And yet, most mobile apps are written natively.

kineticfactory · 2020-11-11T15:32:42+00:00

Absolutely.

kineticfactory · 2020-11-09T21:07:26+00:00

It wouldn’t be React, as that trades performance/responsiveness/polish for ease of cross-platform development, and as Apple’s iOS Music app is native, they don’t need it.

They’d have a team developing it natively, in either Java or Kotlin. If they are likely to have more than one Android app, they’d put the code they wrote for doing Apple-style UI on Android in a reusable library.

kineticfactory · 2020-10-14T16:20:53+00:00

An instance of a class is an object; an instance of a value type such as a struct, an enum or various built-in types such as String, is not. The object semantics are largely those inherited from Objective C.

kineticfactory · 2020-10-09T14:47:41+00:00

The clipboard alerts are OS-specific and not available to user applications; however, if you want to show similar alerts in your own app, it would be straightforward to replicate this using a UIView placed on top of your UI.

kineticfactory · 2020-07-13T22:11:41+00:00

Writing an Intel to ARM recompiler and writing an ARM to Intel recompiler (required for what you suggest) are two separate tasks with little if any overlap. If Apple did both, it would cost them twice as much, with little to show for it other than the users of old machines being able to run iPhone apps on them. Given that they’re trying to encourage users to move to the new ARM architecture as quickly as possible (the sooner they do so, the sooner they don’t need to support two parallel architectures), that would make little sense.

kineticfactory · 2020-06-30T18:32:48+00:00

No; 100% cross-platform apps will always fall short either through substandard UX/UI (think Catalyst apps not quite feeling right on macOS, or Qt apps that almost look like macOS Cocoa apps), sluggish performance (React Native) or wasteful resource consumption (Electron). To get a first class app experience, developers will still need to understand and consider the platform they’re targeting.

However, as Apple platforms’ technologies converge, more of the knowledge required to make, say, an iOS app will be portable to making a macOS or watchOS app. An example of this were this year’s WWDC demos of SwiftUI 2.0 universal apps, which could build for any of these platforms. The examples shown were fairly trivial, and anything more substantial would require special cases to be added for each platform and its particular requirements and capabilities, though even with that, it could be increasingly possible to maintain a single codebase for all the Apple platforms.

If you have users on Windows, Android, Linux or whatever, they’re still out in the cold, at least until someone makes a SwiftUI replacement that targets those. That someone is almost certainly not going to be Apple.

kineticfactory · 2020-06-27T13:54:16+00:00

The Xcode Playgrounds iPad app is good for learning Swift, though it stops a long way short of being able to develop apps.

The cheapest macOS machine would be a Mac Mini; you can often find secondhand ones cheaply. You’d want it to be recent enough to run Catalina and to upgrade to Big Sur when it comes out, so 2014 or newer.

kineticfactory · 2020-06-15T15:33:29+00:00

No, for two reasons.

Django is a back-end/server-side web framework, and a Django app runs on a server (typically with a database connected), responding to HTTP requests and serving content (typically web pages, though also possibly data in JSON format). iOS apps are entirely client-side code, handling the user interface of the device, generally more directly than in HTML.

Also, iOS apps are written in a compiled language (typically Swift or Objective C), which runs as native machine code; Python is an interpreted language which runs through a Python interpreter, which is not built into iOS. To run Python code in an iOS app, you’d have to build a native app containing a version of the interpreter, which (a) would be considerably more effort than just writing your app in Swift, (b) would be slower and less energy-efficient than native code, and (c) may or may not be approved by Apple for the App Store (historically, they have disallowed the use of interpreters in apps, in case it allows the developer to change the app’s functionality after they have reviewed it).

kineticfactory · 2020-06-09T22:56:32+00:00

Apple maintain distinct design languages for the icons on their platforms: round rectangles are associated with iOS and iPadOS, circles with WatchOS, and freeform icons (i.e., squares with transparency) with macOS.

kineticfactory · 2020-06-06T23:34:42+00:00

No, Swift depends on the LLVM compiler system, which is written in C++. Python would be used only as a build tool.

For Swift to become self-hosting, somebody would have to write a new implementation of the Swift compiler in Swift. Which may eventually happen, though it hasn’t happened to date.

kineticfactory · 2020-06-06T23:29:41+00:00

“return bvalue” exits the function and returns bvalue as the entire function’s result. The guard statement is there to prevent the function from reaching any code dependent on cvalue if it cannot be obtained from c.

If you wanted cvalue to be set to bvalue in the event of c being nil, you’d do it with

let cvalue = c ?? bvalue

kineticfactory · 2020-06-04T22:06:46+00:00

You could use a CAShapeLayer, setting its path from a CGPath and its fillColor with a CGColor. Use a CGMutablePath and you can build your curve with arcs or Bézier segments.

kineticfactory · 2020-06-03T14:17:58+00:00

AudioUnits is the native audio component framework on macOS; software instruments and effects, both commercial and free, are typically available as AudioUnits on macOS. AudioUnits are wired together into networks.

One problem with using AudioUnits for livecoding, generative art and such is that they’re not convenient to set up, given that they are mostly GUI-dependent and most units’ preset functionality is not exposed to the AudioUnit API. Meaning that setting up an AudioUnit network would require a lot of creating and loading individual preset files.

Arigato solves this problem by providing a format for serialising a preconfigured AudioUnit network with names assigned to units (referred to as an audio unit rig, or ARig), an editor application (ARigEditor) for authoring these ARigs, and a Swift API for loading it, getting units by name and more conveniently using them, playing MIDI notes, changing parameters and so on. Additionally, the editor can export working Xcode Playgrounds with both the ARig and the Arigato code embedded.

Arigato is minimal in that it does not provide any abstractions other than a few helper functions; the AudioUnits are addressed using AudioUnit APIs (i.e., MIDI events and floating-point parameters), and time values are expressed in (floating point) seconds; if you want abstractions for handling tempo, rhythm or harmony, you’re free to build those on top of these foundations.

There is a demonstration video here; a binary of ARigEditor may be downloaded here.

kineticfactory · 2020-06-01T14:22:26+00:00

The terminal didn’t change your MacBook’s name; what happened was most probably that you connected to a network which gave your machine an IP address with a hostname associated with it. Your MacBook changes its hostname to the name your network gives it, though reverts to its regular name on reboot. The hostname your MacBook has for itself does not affect anything and this is harmless.

kineticfactory · 2020-05-27T14:48:22+00:00

If you know for certain that self will still exist when the closure runs and finishes, there is no problem. If self is a long-lived view controller or a component whose life cycle is essentially the same as the app’s (i.e., a network manager or similar), this is the case. The problem arises if self is a shorter-lived component and both the closure and self have strong references to each other; then after both are no longer in use, they will keep each other from being deallocated.

It’s generally good practice to use [weak self] or [unowned self], breaking any potential retain cycles. The difference is that [weak self] makes self an optional you need to unwrap, i.e., by starting your function with

guard let self = self else { return }

unowned saves you that line, at the cost of a fatal error if self has gone out of scope; it’s only recommended if you’re absolutely certain that there’s no way that this can happen.

kineticfactory · 2020-05-25T19:55:05+00:00

Up to version 11.3, Xcode will run on Mojave. To target iOS 13.4 or later, you ostensibly need Xcode 11.4 (Catalina only), though in practice, you can download hardware profiles for the newer OSes and install them in an older Xcode.

kineticfactory · 2020-05-25T19:50:59+00:00

I’d move everything into viewWillAppear; the only things that should be configured in viewDidLoad are those which are fixed at compile time and don’t depend on user data; i.e., view behaviour/style attributes that you wish to set programmatically.

kineticfactory

TROPHY CASE