Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

I feel like a complete idiot but I keep getting the same error in XCODE on a iOS build:

code:

Signing for "Unity-iPhone Tests" requires a development team. Select a development team in the Signing & Capabilities editor.

And yes, I have assigned a team. And yes, the bundle identifier has the certificate name, and yes the team is assigned to the Provisioning Profile.

What am I missing here? I have released an iOS product (using RenPy) but now I have a Unity team and this is a road block.

# ? Aug 26, 2021 18:33

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 17:23

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

VideoGameVet posted:

I feel like a complete idiot but I keep getting the same error in XCODE on a iOS build:
code:
Signing for "Unity-iPhone Tests" requires a development team. Select a development team in the Signing & Capabilities editor.
And yes, I have assigned a team. And yes, the bundle identifier has the certificate name, and yes the team is assigned to the Provisioning Profile.

What am I missing here? I have released an iOS product (using RenPy) but now I have a Unity team and this is a road block.

Did you assign a team for the tests target?

# ? Aug 26, 2021 18:38

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

pokeyman posted:

Did you assign a team for the tests target?

Yep.

Only registered members can see post attachments!

# ? Aug 26, 2021 18:43

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

pokeyman posted:

Did you assign a team for the tests target?

So I'm still getting

Signing for "Unity-iPhone Tests" requires a development team. Select a development team in the Signing & Capabilities editor.

Will not my account (admin) work for that? Very confused.

# ? Aug 26, 2021 19:35

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

That isn't the test target that you're showing in the screenshot. You also almost certainly want to enable "Automatically manage signing".

# ? Aug 26, 2021 19:42

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

Plorkyeran posted:

That isn't the test target that you're showing in the screenshot. You also almost certainly want to enable "Automatically manage signing".

Here's the target:

Still no joy: Signing for "Unity-iPhone Tests" requires a development team. Select a development team in the Signing & Capabilities editor.

WRONG GRAB

Only registered members can see post attachments!

# ? Aug 26, 2021 20:16

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

Correct Grab:

Only registered members can see post attachments!

# ? Aug 26, 2021 20:17

Centrist Committee: Aug 6, 2019

eschaton posted:

You need to add to both, as iOS and macOS use different underlying UI frameworks (UIKit and AppKit).

eschaton posted:

With Xcode 13, there�s Info.plist generation, so you can put stuff to share between them in the project�s build settings or in an xcconfig file (for supported Info.plist keys, it�s not an open-ended system).

Aight, good to know, thanks.

# ? Aug 26, 2021 22:41

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

VideoGameVet posted:

Correct Grab:

So when I deleted all the targets but Unity-iPhone it compiled and installed (but exited upon launch).

So why would the certs work for that and not the other targets?

It�s a mystery.

VideoGameVet fucked around with this message at 01:11 on Aug 27, 2021

# ? Aug 27, 2021 01:06

awesomeolion: Nov 5, 2007; "Hi, I'm awesomeolion."

VideoGameVet, your issue rings a bell for me. I think you're supposed to set up that crap in Unity before exporting maybe? I seem to remember trying to change some things in a Unity made Xcode project and owning myself, but changing them in Unity and re-exporting worked better.

# ? Aug 27, 2021 03:13

VideoGameVet: May 14, 2005; It is by caffeine alone I set my bike in motion. It is by the juice of Java that pedaling acquires speed, the teeth acquire stains, stains become a warning. It is by caffeine alone I set my bike in motion.

awesomeolion posted:

VideoGameVet, your issue rings a bell for me. I think you're supposed to set up that crap in Unity before exporting maybe? I seem to remember trying to change some things in a Unity made Xcode project and owning myself, but changing them in Unity and re-exporting worked better.

Probabily. Amazing how getting rid of the other targets fixed the problem, even though they had the same Signing & Certificates settings.

# ? Aug 27, 2021 06:56

mdxi: Mar 13, 2006; to JERK OFF is to be close to GOD... only with SPURTING

Is anyone here interested in historical Macintosh dev? I have some old books on the Mac Toolbox that I inherited from a former coworker. They really don't fit into my historical computing collection (more focused on general programming, Unix, and mainframes) so I'd like them to go to a good home. I'm willing to send them to a fellow goon for approximate cost of shipping -- like $20, as they are on the chunky side when combined.

* Macintosh Revealed, Vol 1, Unlocking the Toolbox; Stephen Chernicoff; Apple Press; 1985
* Macintosh Revealed, Vol 2, Programming with the Toolbox; Stephen Chernicoff; Apple Press; 1985
* The Programmer's Apple Mac Sourcebook; Thom Hogan; Microsoft Press; 1989

# ? Sep 5, 2021 20:33

Luigi Thirty: Apr 30, 2006; Emergency confection port.

mdxi posted:

Is anyone here interested in historical Macintosh dev? I have some old books on the Mac Toolbox that I inherited from a former coworker. They really don't fit into my historical computing collection (more focused on general programming, Unix, and mainframes) so I'd like them to go to a good home. I'm willing to send them to a fellow goon for approximate cost of shipping -- like $20, as they are on the chunky side when combined.

* Macintosh Revealed, Vol 1, Unlocking the Toolbox; Stephen Chernicoff; Apple Press; 1985
* Macintosh Revealed, Vol 2, Programming with the Toolbox; Stephen Chernicoff; Apple Press; 1985
* The Programmer's Apple Mac Sourcebook; Thom Hogan; Microsoft Press; 1989

Thaaaaaat�s me. Shoot me a PM if they haven�t been claimed yet.

# ? Sep 6, 2021 09:09

Kreeblah: May 17, 2004; INSERT QUACK TO CONTINUE; Taco Defender

Is there an "Xcode and frameworks for people who are used to makefiles" guide or something similar?

I loving hate trying to build open source projects for Macs, because nine times out of ten, they use broken Xcode projects for Mac builds, which were originally built using an Xcode version from like five years prior, and require frameworks that need to be built from source (from Xcode projects which are also broken).

To date, I don't think I've yet succeeded in building one. Every single time, I've had to figure out what they were trying to do, rip out the Xcode project and framework crap, and add Mac build support (using headers and libraries, as God intended) to the already-existing makefile that the project already loving has. It's tedious, though, and I keep thinking I'm missing something.

# ? Sep 6, 2021 20:23

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Kreeblah posted:

Is there an "Xcode and frameworks for people who are used to makefiles" guide or something similar?

I loving hate trying to build open source projects for Macs, because nine times out of ten, they use broken Xcode projects for Mac builds, which were originally built using an Xcode version from like five years prior, and require frameworks that need to be built from source (from Xcode projects which are also broken).

To date, I don't think I've yet succeeded in building one. Every single time, I've had to figure out what they were trying to do, rip out the Xcode project and framework crap, and add Mac build support (using headers and libraries, as God intended) to the already-existing makefile that the project already loving has. It's tedious, though, and I keep thinking I'm missing something.

If you're in luck, the Makefile is generated by CMake or similar, which you can use to generate a more modern Xcode project. Otherwise, I've sometimes made a new Xcode project and dragged the files in, trying to replicate what the Makefile does. I'm not sure if that's exactly what you're describing in your last paragraph, or if I'm going in the opposite direction, but either way it's pretty tedious.

I think there's a somewhat reasonable way to add an Xcode target that points at a Makefile, and so long as you point the dependant targets at the right header and library paths it mostly works, but I don't remember any of the details.

# ? Sep 6, 2021 20:33

Kreeblah: May 17, 2004; INSERT QUACK TO CONTINUE; Taco Defender

pokeyman posted:

If you're in luck, the Makefile is generated by CMake or similar, which you can use to generate a more modern Xcode project. Otherwise, I've sometimes made a new Xcode project and dragged the files in, trying to replicate what the Makefile does. I'm not sure if that's exactly what you're describing in your last paragraph, or if I'm going in the opposite direction, but either way it's pretty tedious.

I think there's a somewhat reasonable way to add an Xcode target that points at a Makefile, and so long as you point the dependant targets at the right header and library paths it mostly works, but I don't remember any of the details.

No, I end up going in the opposite direction, by throwing out Xcode entirely, and having the makefile (or whatever) do the whole build. It ends up being easier to just do that (especially if they already have something like CMake set up, which can spit out an app bundle) rather than trying to either unfuck the Xcode project or make a new one from scratch.

# ? Sep 6, 2021 20:58

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Most open source projects shouldn�t really need an Xcode project, as long as their make-based build system is sufficiently sane. (Looking at you, SIMH, grr.) Where you�ll generally want an Xcode project is in producing an app or other Mac-specific artifact on top of something cross-platform.

That said, Xcode and make aren�t that different: You can consider an Xcode project like the primary makefile, and the Xcode targets like either major targets in that makefile or like �modules� with their own makefile a la recursive make.

The main difference is that individual source or object files aren�t targets themselves like they are in make, and there are tons of independent settings for things the typical makefile will shove into CFLAGS etc. and a means of easily organizing those settings into configurations and also inheriting them via the �layering� mechanism.

A project�s configurations� settings can be based on xcconfig files, and those will be inherited by the project�s targets as well. The list goes like this, where each subsequent item can override from the previous items: Xcode default values, project-xcconfig, project, product and target type, target-xcconfig, target, xcodebuild command line arguments.

The main cause for me to make an Xcode project to build something like SIMH is when I notice its makefile is really really bad and doing a ton of redundant work. (SIMH in particular could build a couple libraries and also compile a bunch of the shared object files between eg the multitude of PDP and VAX simulators independently, saving a huge amount of time.) I could have written a better makefile or used CMake, but with Xcode I can just throw that stuff together, maintain it simply, and focus on actually debugging and running stuff. And it�s not like I can contribute my changes (would have to get work approval) or like the maintainer would take my changes anyway (he gets real pissy when I criticize his makefile or choice of compiler warnings to silence). So I have my Xcode stuff off to the side and just use that on my Macs, and on NetBSD I just use his makefile.

# ? Sep 6, 2021 21:11

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Xcode was Real Bad about every single version breaking things until 5 or 6, but at this point I'd expect a non-Swift macOS project that hasn't been touched in five years to build in Xcode 13 without any issues. There was a whole series of painful migrations from gcc -> weird gcc/llvm hybrid -> clang, libstdc++ -> libc++, and developer tools being installed system-wide to being mostly contained inside Xcode which kept breaking everything every year, but that's all long done with.

# ? Sep 6, 2021 22:01

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Also, yeah, a lot of xcodeprojs checked into open-source repositories are just there so you can browse/edit with xcode, not with the idea that you should be primarily building through the IDE.

# ? Sep 7, 2021 01:04

uncle blog: Nov 18, 2012

Are there any decent physical Swift conferences happening this year or early next year?

# ? Sep 10, 2021 11:23

uncle blog: Nov 18, 2012

I want our app to let users (who are not registered on a particular website) to be sent to their registration page (either via a webview modal or something) and then return to our app, and let the app know that the registration was successful. I'm guessing this is similar to what happens when switch to Facebook to log on to something, and then the app sends you back to the previous app which now knows that you are authenticated.

What is this called? Is there a specific API in UIKit for this? What does the webpage need to do to make this possible?

# ? Sep 14, 2021 11:57

spaced ninja: Apr 10, 2009; Toilet Rascal

Looks like you are looking for a OAuth flow.

https://developer.apple.com/documentation/authenticationservices

# ? Sep 14, 2021 13:44

Stringent: Dec 22, 2004; image text goes here

*edit*

nm

Stringent fucked around with this message at 04:23 on Sep 17, 2021

# ? Sep 17, 2021 03:54

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

I don't want to be mean to the GSOC student but https://forums.swift.org/t/pitch-introduce-expanded-parameters/51885 seems like a really terrible idea that'd be incredibly confusing for very little benefit.

I am very excited for shared storage for property wrappers though, especially if it ends up being back-deployable so that we can actually rely on it.

# ? Sep 24, 2021 03:48

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Plorkyeran posted:

I don't want to be mean to the GSOC student but https://forums.swift.org/t/pitch-introduce-expanded-parameters/51885 seems like a really terrible idea that'd be incredibly confusing for very little benefit.

A lot of APIs take a lot of configuration options as a struct, and this means you can pass in the options directly instead of having to separately construct an options value. I know that sounds like a corner case of expressivity, but I think it's an important niche. What happens typically is that APIs struggle with how convenient to make passing configuration: usually the best abstraction is to have an options struct, but it's really annoying to have to construct one just to pass a single option. That's especially true if that argument is mandatory and so every caller will pass it even if they don't need to override anything else: it's part of the abstract configuration, so you want it in the options struct, but now the syntactic (and readability) burden of calling your API just went up a lot. In the best case, you end up with something where there are a handful of convenience functions that let you just pass the most common configuration options, defined in terms of a fully-general API that takes the options struct:

Swift code:

struct ConnectionOptions {
  var url: URL
  var authentication: AuthenticationOptions?
  var maxProtocol: Version?
  var encodingBufferSize: Int = 65536
}

func connect(to url: URL) {
  connect(options: ConnectionOptions(url: url))
}
func connect(to url: URL, authentication: AuthenticationOptions) {
  connect(options: ConnectionOptions(url: url, authentication: authentication))
}
func connect(options: ConnectionOptions) { ... }

This promotes a ton of boilerplate at every place that takes options. That in turn leads to annoyances for clients when the boilerplate is slightly different for closely related APIs: maybe one convenience API uses slightly different argument labels, or it doesn't allow you to pass the same set of convenience options, or it accidentally uses different defaults, or it isn't updated after a new option is added, or it just decides to punt on the problem and only take the options struct, making it less convenient to use for no good reason. With expanded parameters, any API that takes a set of configuration options should just provide a single function taking the options struct as an expanded parameter. Voil�, a permanently consistent and ABI/API-stable solution.

It's very nice for introducing these option structs, too. That's a very common path of code evolution: you start off just taking a bunch of different options as different arguments, and then you realize you have a good reason to abstract over that, maybe because you want to introduce an intermediate abstraction or you need to serialize them or print them or accumulate them through some dynamic configuration or something similar. With expanded parameters, you just move the parameters into an options struct and take it expanded, and bam, you've got your abstraction with minimal boilerplate and without breaking any call sites.

# ? Sep 24, 2021 06:52

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

My first thought was that the proposal boils down to no longer having to type the seven characters .init( and ) to create your e.g. options struct, but the code evolution part makes it more compelling to me.

# ? Sep 24, 2021 07:35

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

In that simplest use-case of a function which takes a single struct it does save a nice bit of boilerplate, but the only bit there that excites me as a SDK developer is that it ensures I can't forget to expose new parameters (and that is pretty exciting). AFAICT it doesn't enable anything that isn't currently possible.

The downside is that everything more complicated than that most simple case is really confusing. How does it interact with overloading? Any answer other than overloading is forbidden will inevitably surprise and confuse people. Multiple @expand arguments to a function has all these wacky edge-cases. If overlapping labels go to the first one (or are a compile error), then adding fields to your struct is a breaking change, and if it goes to the second then you just can't pass some parameters? The pitch currently says that you have to have a non-expanded, non-default parameter in between them, which avoids the problem but is incredibly awkward.

The whole thing just seems like a feature specifically crafted to produce highly upvoted SO questions without the upside to justify that.

# ? Sep 24, 2021 16:30

fankey: Aug 31, 2001

My app supports user supplied fonts which I draw with CATextLayer. Most fonts work just fine but some are 'bullshit fonts' like this one - https://www.dafont.com/cubic.font. In that font the author decided to have font content go below the descender ( noted below with the yellow line ). I'm not sure that's legal for a font. I do have rendering implementations based in both Qt and WPF that render the font fine but I'm struggling with trying to get iOS to not clip the bottoms off.

I'm able to read the UIFont.ascender and UIFont.descender to adjust my bounds and offsets so I don't clip things within those but I can't figure how to to determine, for a particular font, how much it extends beyond the descender. Is this possible with UIFont?

# ? Oct 8, 2021 17:15

duck monster: Dec 15, 2004

Have apple given a technical reason for not supporting 2014-2015 MBPs? I've a late 2014/purchased in 2015 MBP and it runs big sur just fine, but it would appear I cant get the new OSX. Which is a problem for an app developer, obviously. And I just dont have the cash to upgrade. Is this something the hacker community might be able to fix like has happened in the past with arbitrary minimum spec releases, or is there genuine hardware requirements here?

# ? Oct 19, 2021 05:57

commie kong: Mar 7, 2019

duck monster posted:

Have apple given a technical reason for not supporting 2014-2015 MBPs? I've a late 2014/purchased in 2015 MBP and it runs big sur just fine, but it would appear I cant get the new OSX. Which is a problem for an app developer, obviously. And I just dont have the cash to upgrade. Is this something the hacker community might be able to fix like has happened in the past with arbitrary minimum spec releases, or is there genuine hardware requirements here?

I had this question and can pass along the useful response i received!

Binary Badger posted:

commie kong posted:
drat, I have a 2014 that I thought had dropped out of upgrade support. Did you need some tricks to get that working?

I used this:

https://github.com/dortania/OpenCore-Legacy-Patcher

Start here:

https://dortania.github.io/OpenCore-Legacy-Patcher/START.html

Fairly simple and straightforward, just have Mojave or later installed, apply the patcher, reboot, then run the macOS installer that you couldn't before.

I use an earlier version of Open Core on my MacPro 5,1 to give it the ability to use the Radeon 580's GPU for video acceleration (most notably the ability to run Netflix, something that Apple seems to have deliberately gelded from Mojave and the 5,1) and a boot screen with my third party 580.

Haven't tried to install Big Sur on my 5,1 yet, but will relish doing so on a Mac Mini 2012 I picked up at a Goodwill..

# ? Oct 19, 2021 06:36

duck monster: Dec 15, 2004

commie kong posted:

I had this question and can pass along the useful response i received!

Hmm. Thats one for the bookmarks, though since I have Big Sur running already, I might hold out until I know It'll still work for updating to Montery

edit: oh my god, those new M1 Max machines. 64gig + 8TB hdd, $6K....... *muffled credit card screams*

duck monster fucked around with this message at 13:12 on Oct 19, 2021

# ? Oct 19, 2021 07:56

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

duck monster posted:

Hmm. Thats one for the bookmarks, though since I have Big Sur running already, I might hold out until I know It'll still work for updating to Montery

edit: oh my god, those new M1 Max machines. 64gig + 8TB hdd, $6K....... *muffled credit card screams*

If it helps, the M1 MacBook Air is pretty great for app dev and should be much less than $6k.

# ? Oct 19, 2021 14:39

take boat: Jul 8, 2006; boat: TAKEN

duck monster posted:

edit: oh my god, those new M1 Max machines. 64gig + 8TB hdd, $6K....... *muffled credit card screams*

the 16" M1 Max with 32gb/512gb for 3100 isn't bad for their near top end MBP. I would consider it except working from home, I cheaped out with a $600 M1 mini which has been great for everything (except Swift UI previews)

I could probably always use more cores so if there's ever a 2k or 2.5k midrange pro desktop...

# ? Oct 21, 2021 01:46

uncle blog: Nov 18, 2012

Is coding in SwiftUI with live preview slow as poo poo for everybody? Have a pretty high end MBP from 2018, and XCode hangs and acts up all the time.

# ? Oct 21, 2021 12:42

duck monster: Dec 15, 2004

uncle blog posted:

Is coding in SwiftUI with live preview slow as poo poo for everybody? Have a pretty high end MBP from 2018, and XCode hangs and acts up all the time.

Seems not much changes with Apple IOS toolkits then. The old springs-and-weights autolayout system in XCode was pretty good at reducing even an absolute bulldozer of a machine a smouldering ruin.

# ? Oct 26, 2021 08:42

take boat: Jul 8, 2006; boat: TAKEN

duck monster posted:

Seems not much changes with Apple IOS toolkits then. The old springs-and-weights autolayout system in XCode was pretty good at reducing even an absolute bulldozer of a machine a smouldering ruin.

that's interesting, I don't remember XCode/Interface Builder ever being slow when working with springs and struts or autolayout in the visual designer

I definitely remember periods where it was very crashy and a PITA for that and other reasons. the visual designer's big advantage is not needing to compile any project code (IBDesignable/IBInspectable notwithstanding), which I think is the bulk of the issue with SwiftUI previews

# ? Oct 26, 2021 15:43

duck monster: Dec 15, 2004

take boat posted:

that's interesting, I don't remember XCode/Interface Builder ever being slow when working with springs and struts or autolayout in the visual designer

I definitely remember periods where it was very crashy and a PITA for that and other reasons. the visual designer's big advantage is not needing to compile any project code (IBDesignable/IBInspectable notwithstanding), which I think is the bulk of the issue with SwiftUI previews

It would be a problem with larger more complicated designs. I worked at a company that made a rather complicated ERP product, and some of the ipad screens had hundreds of elements on the screen, and I'd see xcode just choke to the point it'd need a hard kill -9 to stop the whole machine from crashing under the memory load. We upgraded to top of the line (for the time) imac w/ 64gig ram, but even that would eventually poo poo itself if you spent too much time working on the screen.

I *really* prefer just doing all this stuff in code, but we worked with graphic designers who insisted on them being able to edit the screens, so the boss ruled against me. It was a pita.

# ? Oct 27, 2021 03:45

Pulcinella: Feb 15, 2019

Yeah Interface Builder works great if you are just using it to grey box the UI layout (I actually really, really like Interface Builder, merge conflicts aside, and it feels very fast to layout complicated hierarchies to me). IBInspectable and IBdesignable never really worked very well, in my experience, and we generally avoid them. IBDesignable is amazing feels like magic�when it works. The problem is IBdesignable views can potentially take a lot of code work to setup properly, work that is usually specific to functioning in IB and isn�t actually needed for the app to work properly. Also sometimes you do everything perfect and they still break anyway.

But yeah SwiftUI previews are incredibly slow on my 2019 16 inch 8 core Intel MacBook Pro. They start off fine and then just get progressively slower until I have to restart XCode. It even affects the editing experience in files that don�t have previews. Multi second delay between typing and those characters appearing on screen. I�m interested in seeing how the the new Swift Playgrounds app turns out on iPad. iOS SwiftUI previews on Mac are basically modified simulators, but the iPad might just be able to run the compile views �natively.�

# ? Oct 27, 2021 17:09

take boat: Jul 8, 2006; boat: TAKEN

duck monster posted:

It would be a problem with larger more complicated designs. I worked at a company that made a rather complicated ERP product, and some of the ipad screens had hundreds of elements on the screen, and I'd see xcode just choke to the point it'd need a hard kill -9 to stop the whole machine from crashing under the memory load. We upgraded to top of the line (for the time) imac w/ 64gig ram, but even that would eventually poo poo itself if you spent too much time working on the screen.

I *really* prefer just doing all this stuff in code, but we worked with graphic designers who insisted on them being able to edit the screens, so the boss ruled against me. It was a pita.

ha, this was with autolayout? was layout slow at runtime with all that?

# ? Oct 28, 2021 02:12

Adbot: ADBOT LOVES YOU

# ? May 31, 2024 17:23

Pulcinella: Feb 15, 2019

Xcode 13.2 Beta posted:

You can now use Swift Concurrency in applications that deploy to macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes async/await, actors, global actors, structured concurrency, and the task APIs. (70738378)

https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes

:toot:

# ? Oct 28, 2021 02:25

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›354 »