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 »

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

New to Swift UI and I'm trying to do something like this:

I'd normally reach for NSAttributedText for this purpose but I'd like to do it with Swift UI if possible. I found a StackOverflow post approach this by wrapping NSAttributedText so that they can use it in a Swift UI way. Not sure how I feel about that.

I thought maybe I could do it just by combining Text but that seems like it's not going to ever work with the many ways text content can flow:

If there's no Swift UI way to give a substring of Text a background I think I might call this experiment complete and go back to the old robust way of doing things :shrug:

# ? May 3, 2020 00:03

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 07:32

Data Graham: Dec 28, 2009; 📈📊🍪😋

So my late-90s battle scars are itching something fierce. Is Apple about to find itself staking out a shrinking ghetto by not supporting WebP?

Seems like Chrome penetration is at a high enough level that people are tossing WebP files around via imgur and other such places without even realizing they're not using a "standard" image format. Much like in the days when it quickly became apparent that you couldn't educate people not to send "binaries" to newsgroups because they don't know what "binaries" are, they're just using their seamless WYSIWYG news posting app to send images to the group, what's the problem?

I'm really not feeling like I want to die on the hill of being the crank Safari/iOS user who only has himself to blame for not being able to see the funny image someone posted but still feels the need to grouse in public about it.

# ? May 4, 2020 20:36

KidDynamite: Feb 11, 2005

https://forums.swift.org/t/accepted-se-0279-multiple-trailing-closures/36141/83

Why is this change so mind bending for the community? Wonder what the folks here think of it. I don't particularly like it and I don't think it will ever result in a breaking change due to abi stability but it's just not that big a deal.

# ? May 8, 2020 15:48

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

KidDynamite posted:

https://forums.swift.org/t/accepted-se-0279-multiple-trailing-closures/36141/83

Why is this change so mind bending for the community? Wonder what the folks here think of it. I don't particularly like it and I don't think it will ever result in a breaking change due to abi stability but it's just not that big a deal.

It's a quintessential bike shed. It's almost impossible to use Swift without interacting with trailing closures (either using them at least sometimes, or strenuously avoiding them), which gives everyone relevant experience.

Personally, I've never figured out my preference for trailing closures. I think it was rjmccall who saw it as a way for user-defined functions to resemble language keywords (e.g. a lock() method that takes a closure for its critical section), which makes sense to me. I usually think trailing closures look silly as completion or action blocks (e.g. URLSession or UIViewController.dismiss). And having a trailing closure when some earlier parameter takes a closure often looks weird (e.g. UIView.animate), and either of the current syntaxes can seem clearer to me depending in the situation, so I get the motivation to change call sites with multiple closures.

I think I'd prefer fewer choices, so I don't have to make a decision when calling functions, and so I have less to think about when deciding how to spell new functions. I don't mind the parentheses and the commas. But mostly I don't really care, which makes some of the reactions in that thread feel extreme to me. If I participated in the evolution process I'd have voted "apathetically against".

# ? May 8, 2020 16:47

Fate Accomplice: Nov 30, 2006

KidDynamite posted:

https://forums.swift.org/t/accepted-se-0279-multiple-trailing-closures/36141/83

Why is this change so mind bending for the community? Wonder what the folks here think of it. I don't particularly like it and I don't think it will ever result in a breaking change due to abi stability but it's just not that big a deal.

I don't mind it for single closured-calls, but it's gonna be weird if the first of multiple closures trails without a label but all subsequents are labeled.

# ? May 8, 2020 17:01

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

My preference would have been to also allow a label on the first trailing closure, but I think the accepted syntax does represent progress even if there are some APIs it�s not really appropriate for without that label.

There�s essentially three very different camps in the opposition here, which is easy to miss, and which I think some people were (perhaps intentionally) overlooking in order to portray the community as being uniformly opposed. The first camp agrees with my position: they want the first trailing closure to be labelable so that the syntax can be used with more APIs. The second camp wants that label to be required unless the API opts in � and they�d really prefer if that could be applied even to single trailing closures. And the third camp doesn�t like trailing closures at all and doesn�t want anything to be done that encourages their further use.

My first thought when I first looked at this was that requiring the label would be fine, but then people convinced me that most APIs that take trailing closures are not �symmetric�: that there�s usually a primary closure whose label doesn�t convey much, and the syntax would be quite a bit more valuable if it worked better for those cases. Of course that doesn�t mean Swift shouldn�t even allow a label on the first closure, but there are reasons we ended up here, and it was a compromise I could accept, especially because the syntax doesn�t foreclose that possibility at all.

# ? May 10, 2020 05:36

Doc Block: Apr 15, 2003; Fun Shoe

Bob Morales posted:

I created this mapview deal, and then I want to do a thumbnail view up above. Do I have the mapview update the controller (that handles the zoom slider) and then have the controller relay that back to the thumbnail view? (coordinates of current view, size of the mapview, and the current zoom factor so it can generate a colored box the size of the current 'view')

It's not really a thumbnail but an indicator of where the current view is on the grand scheme of however large the map coordinates could be. But anyway.

That just seems...kind of goofy. Maybe I should just have the mapview draw the thumbnail opaquely in the corner of itself. It'd be simpler.

But then what am I going to do when I allow the user to select walls/things, and need to show the texture and other info related to that object? Would I have a property of the mapview with the ID of the currently selected object, and then just highlight that in another window that has all the textures? Something like [[self superview] updateToolsWindow]?

I do like one Cocoa project every 3 years and can never remember the best ways to link up different views.

I wouldn't put any logic in the MapView beyond what is needed to display the map. You could have the view controller post a notification when the view coords/zoom/etc change, with the accompanying info, and have your thumbnail view listen for that and redraw when it changes.

As to the user selecting walls etc., I've used Cocoa Bindings for handling object editing in map editors before and it saved me from having to write a lot of glue code. It's been a long time, but basically you have your model objects adhere to key value observing (and key value coding) and put them in an NSArray. Make your object editor in Interface Builder and wire everything up to Cocoa Bindings via the various controller objects (such as NSArrayController). You have to write like one line of code to connect the NSArrayController to your array of model objects.

Then, whenever the user selects an object or wall or whatever, you tell the array controller that the user selected Object 5, and Cocoa Bindings takes care of plucking out all the values from that object and stuffing them into your UI. And it's bidirectional, so when the user changes something about that object in the UI, Cocoa Bindings updates your model object for you.

And if you go down the Cocoa Bindings route, you could wire up your thumbnail view to your map view with it as well.

edit: dug up this screenshot of an unfinished map editor I made for a little Wolfenstein3D-style raycasting engine I was building. The user could add/remove/select walls in the map view, and the wall texture selection panel on the right behaved as you'd expect (selecting a wall would highlight its texture, selecting a different texture would update the wall, etc.), with the currently selected wall texture shown in larger size at the top, and all that was hooked up with Cocoa Bindings.

Doc Block fucked around with this message at 12:05 on May 11, 2020

# ? May 11, 2020 11:45

SaTaMaS: Apr 18, 2003

A penetration tester went through my app at work, and one thing they flagged was that stack-smashing protection was off. The way this is checked is by looking for flags in the binary using "otool -I -v AppName|grep stack" and looking for ___stack_chk_fail/___stack_chk_guard. These flags seem to appear in apps that use obj-c but not swift-only apps. I suspect that ssp is on in swift-only apps but the flags are getting stripped out, but can't find any confirmation, has anyone dealt with this before?

I'm reading some stuff saying that the flags might show up in an ad-hoc deployment IPA, but I can't generate those with my work certificate

SaTaMaS fucked around with this message at 19:25 on May 11, 2020

# ? May 11, 2020 18:52

Doh004: Apr 22, 2007; Mmmmm Donuts...

Anyone know if you can block regions/countries/zones for public Testflight downloads? I know you can do this in App Store listings but I'm not sure if you can with non-released apps.

We're looking to send out TF builds via emails to specific users so this should be less of an issue but that doesn't guarantee that person couldn't be in a place we don't want them to be.

# ? May 15, 2020 15:29

KidDynamite: Feb 11, 2005

Data Graham posted:

So my late-90s battle scars are itching something fierce. Is Apple about to find itself staking out a shrinking ghetto by not supporting WebP?

Seems like Chrome penetration is at a high enough level that people are tossing WebP files around via imgur and other such places without even realizing they're not using a "standard" image format. Much like in the days when it quickly became apparent that you couldn't educate people not to send "binaries" to newsgroups because they don't know what "binaries" are, they're just using their seamless WYSIWYG news posting app to send images to the group, what's the problem?

I'm really not feeling like I want to die on the hill of being the crank Safari/iOS user who only has himself to blame for not being able to see the funny image someone posted but still feels the need to grouse in public about it.

This seems like Google is forcing it because I'm clearly looking at something stored as a jpg and downloading it changes it to a webp when I'm in chrome and it's a jpg when I'm in safari which is total bullshit.

# ? May 15, 2020 15:58

lord funk: Feb 16, 2004

Ugh. I understand the changes in Swift to the UnsafeMutablePointer, but gently caress I wish it would just be left alone.

Moving from grabbing the unsafe pointer (that yes, is technically invalid by the time you finished creating it) to 'withUnsafeMutableBufferPointer' changes the way the access works, with 'didSet' being called now.

I just want not-mollasses slow array access, leave me alone.

# ? May 16, 2020 14:42

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

You're taking the address of a variable with a didSet and your complaint is that didSet is being called after you do the modification instead of I guess before it?

Or are you using withUnsafeMutableBufferPointer for some reason when you actually don't want mutability?

# ? May 16, 2020 20:44

lord funk: Feb 16, 2004

rjmccall posted:

You're taking the address of a variable with a didSet and your complaint is that didSet is being called after you do the modification instead of I guess before it?

Or are you using withUnsafeMutableBufferPointer for some reason when you actually don't want mutability?

So, this is how I have been reading / writing to arrays in an unsafe way:

code:

        var a: [Int] = [] {
            didSet {
                ...
            }
        }

        let p = UnsafeMutablePointer<Int>(mutating: a)
        p[0] = 10

In this example, the didSet does not get called. I always presumed it was because I was playing at a low level, knowingly and intentionally (UNSAFE), and so the Swift extras do not get applied. Basically, turns it into a C array, right?

Latest Xcode complains that the pointer 'p' results in a dangling pointer. My understanding is that I am being encouraged to use withUnsafeMutableBufferPointer instead, with the block where that pointer is valid. I'm okay refactoring to that, but now it does call the didSet. Why? Isn't this supposed to just give me low level access, and get out of the way?

I'm now worried that extra Swift calls are going to lock / unlock / check / uncheck for my high-traffic array modifications and slow things down. Like, the point of going the unsafe route was to avoid that.

# ? May 16, 2020 22:04

brand engager: Mar 23, 2011

Have you profiled this to see if you even need to be using unsafePointers?

# ? May 16, 2020 22:25

lord funk: Feb 16, 2004

brand engager posted:

Have you profiled this to see if you even need to be using unsafePointers?

Yep. I'm making a 3D engine in Metal, and there is a lot of low-level optimization so Metal doesn't get bottlenecked by CPU stuff. One of the earliest, biggest optimizations was moving to unsafe pointers to update vertex information.

lord funk fucked around with this message at 22:46 on May 16, 2020

# ? May 16, 2020 22:44

brand engager: Mar 23, 2011

I couldn't find anything on why didSet gets called, but supposedly making an unsafePointer to an array just makes a pointer to the storage space which might become invalid because the whole array might get replaced if you modify any elements.

https://forums.swift.org/t/help-rid-of-warning-with-unsafemutablepointer-with-array-withunsafemutablepointer/34364/2

quote:

UnsafeMutablePointer(mutating:) takes a pointer argument. Passing an array results in passing the address of the element storage to the initializer.

https://stackoverflow.com/a/49001625

quote:

Any change to it replaces the entire array with a completely different array. Swift has some clever copy-on-write tricks to make this efficient, and in practice it may not actually replace the entire array, but you should program as though it did.

# ? May 16, 2020 23:38

lord funk: Feb 16, 2004

Right, I'm not complaining that changing it to make it write-safe is a bad thing. That's fine. I'm just curious why something I consider to be Swift 'sugar' is now part of accessing the collection at a lower level.

I like that you can use Swift's array features to create / resize / filter / map / etc.. It makes coding much nicer. Then, when you really need to get down to the nuts and bolts for speed, you can use the unsafe pointers.

# ? May 17, 2020 00:11

brand engager: Mar 23, 2011

I think didSet is getting called automatically after withUnsafeMutableBufferPointer returns and the normal value watching stuff isn't seeing whatever low-level changes happened. For example I did this in the repl:

code:

var junk = [1, 2, 3, 4] {
    didSet {
        print("didSet")
    }
}
junk.withUnsafeMutableBufferPointer { ptr in
    ptr[0] = 2
    ptr[1] = 3
}

and it printed "didSet" once. It also prints it once if I do

code:

junk.withUnsafeMutableBufferPointer { ptr in
}

with no changes made to the array

# ? May 17, 2020 00:33

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

lord funk posted:

So, this is how I have been reading / writing to arrays in an unsafe way:

Oh god, that really shouldn�t be so easy. This is literally building a non-mutating pointer to the array and then casting it to be mutable. You are completely subverting the basic value semantics of arrays.

# ? May 17, 2020 00:47

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

didSet should be getting called whenever you mutate a variable with a didSet. If you don't want that, consider not explicitly and intentionally adding a didSet to the variable.

# ? May 17, 2020 06:26

lord funk: Feb 16, 2004

I was unclear: I am not against calling didSet after withUnsafeMutableBufferPointer. I just got real worried that Swift was trying really hard to save me from myself inside the block too.

So, just to be clear, this is okay? Or am I committing some unheard of horror.

code:

var a: [Int] = [1, 2, 3, 4, 5]

a.withUnsafeMutableBufferPointer{ p in 
    for i in 0..<p.count {
        p[i] = ...
    }
}

# ? May 17, 2020 13:51

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

Nope, that�s just how you should be doing it.

# ? May 17, 2020 17:04

Doh004: Apr 22, 2007; Mmmmm Donuts...

How concerned do I need to be that OpenGL has been deprecated for "2 years" now and won't work in iOS 14?

# ? May 22, 2020 19:32

lord funk: Feb 16, 2004

Doh004 posted:

How concerned do I need to be that OpenGL has been deprecated for "2 years" now and won't work in iOS 14?

Where are you seeing it as "won't work" in iOS 14? I'm only seeing rumors.

# ? May 22, 2020 20:31

Doh004: Apr 22, 2007; Mmmmm Donuts...

lord funk posted:

Where are you seeing it as "won't work" in iOS 14? I'm only seeing rumors.

Trying to assuage fears with my boss/other engineers. Apple's been trying to get us to move off of OpenGL for the past year and we're worried things will "stop working" in iOS 14 and cause crashes. I personally don't think this because it'd be a loving mess for Apple but wanted to get checked on it.

# ? May 22, 2020 22:58

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

I don't have any specific information about this � I don't follow that sort of thing at all � but if Apple's been directly reaching out to your company and telling you to get off OpenGL and you've been blowing them off for a year saying that there's no way they could possibly mean it, I mean, you are misunderstanding the dynamic here pretty badly.

# ? May 22, 2020 23:01

Doc Block: Apr 15, 2003; Fun Shoe

Yeah, they�re basically telling you that OpenGL is gonna get removed in iOS 14.

Is there a reason you haven�t switched to Metal already? Or even Vulkan-on-Metal with MoltenVK or something?

# ? May 22, 2020 23:06

Doctor w-rw-rw-: Jun 24, 2008

I'd rate the odds that Apple ramps up pushing Metal over OpenGL in the next year at "virtually certain". They've certainly spent enough time killing Imagination's entire stack from driver to silicon in the past several years.

# ? May 23, 2020 02:43

Doh004: Apr 22, 2007; Mmmmm Donuts...

Doc Block posted:

Yeah, they’re basically telling you that OpenGL is gonna get removed in iOS 14.

Is there a reason you haven’t switched to Metal already? Or even Vulkan-on-Metal with MoltenVK or something?

I only joined current place 3 months ago so my answer as to why hasn't it happened yet is "prioritization". It's not a core part of our application or service (file sync and sharing) and it was built back in like 2014 in C++ so it's not really a part of the codebase we have a current competency in.

rjmccall posted:

I don't have any specific information about this � I don't follow that sort of thing at all � but if Apple's been directly reaching out to your company and telling you to get off OpenGL and you've been blowing them off for a year saying that there's no way they could possibly mean it, I mean, you are misunderstanding the dynamic here pretty badly.

Been working with Apple for a while, I "get it", but I also "get" the dynamic of Apple caring a ton more about its applications working off of the App Store. From what I've been told, they've been asking us to do it - not telling us to do it, hence me wanting to run it by people here that I've known to be in the business for a while.

Doctor w-rw-rw- posted:

I'd rate the odds that Apple ramps up pushing Metal over OpenGL in the next year at "virtually certain". They've certainly spent enough time killing Imagination's entire stack from driver to silicon in the past several years.

Ramps up as in "As of 14.0, OpenGL APIs no longer exist and any applications built and targeting this will no longer compile"? Would like to avoid that next month when WWDC happens and the iOS 14 beta rolls out and we're trying to compile our applications against it.

# ? May 23, 2020 15:48

Doctor w-rw-rw-: Jun 24, 2008

It's Apple, they'll stop accepting updates to the App Store before they drop software support. I would not be surprised if they gave a short timeline to dropping support; they've already spent a couple of years with companies telling them to get on board with Metal; Metal just wasn't ready yet (i.e. shader compilation toolchain needing work).

# ? May 23, 2020 20:30

lord funk: Feb 16, 2004

Doc Block posted:

Is there a reason you haven�t switched to Metal already?

Speaking as someone with OpenGL apps on the store for going on 10 years now, I haven't switched because it's a pointless rewrite of an entire graphics system with no benefit to my app. OpenGL isn't the bottleneck in my app's performance, and there is nothing gained by switching to Metal.

If this is true it just means a complete waste of time and effort to continue supporting an app that works perfectly fine.

# ? May 23, 2020 21:19

jabro: Mar 25, 2003; July Mock Draft 2014

1st PLACE
RUNNER-UP
got the knowshon

WTH, sorry

# ? May 23, 2020 22:24

Doctor w-rw-rw-: Jun 24, 2008

lord funk posted:

Speaking as someone with OpenGL apps on the store for going on 10 years now, I haven't switched because it's a pointless rewrite of an entire graphics system with no benefit to my app. OpenGL isn't the bottleneck in my app's performance, and there is nothing gained by switching to Metal.

If this is true it just means a complete waste of time and effort to continue supporting an app that works perfectly fine.

If I'm channeling Apple's egocentrism, it's not that it's working perfectly fine, but that Apple has to continually invest in maintaining someone else's stack to be compatible as their own hardware and software designs to move forward with newer products. They'd rather invest in making their own stack work better, and pave the way with Unreal and Unity support to cover most games automatically, with better performance.

If you're good enough to write your own OpenGL support then you're good enough to write your own Metal, given a couple of years to do so, or so the logic would go.

So yeah Apple probably would rather you just get onboard their ship since it's either them or you and they chose you.

# ? May 24, 2020 10:12

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

rjmccall posted:

I don't have any specific information about this � I don't follow that sort of thing at all � but if Apple's been directly reaching out to your company and telling you to get off OpenGL and you've been blowing them off for a year saying that there's no way they could possibly mean it, I mean, you are misunderstanding the dynamic here pretty badly.

Yeah it�s sorta like the UIWebView thing recently. I was sounding the alarm at work for a while like �this one seems different guys...� Sure it was deprecated for years before then, but you don�t get emails about it. There�s been tons and tons of WebKit-related sec issues, so it makes sense that embedding a full WebKit engine inside your app makes no sense from their perspective.

Fast forward a few weeks after a ticket-argument where someone said �we�ll update when Apple makes us� and Apple is all �hard stop no new app submissions after April and get that poo poo out by Dec�.

# ? May 24, 2020 12:57

lord funk: Feb 16, 2004

Doctor w-rw-rw- posted:

So yeah Apple probably would rather you just get onboard their ship since it's either them or you and they chose you.

Yeah, this is by far the worst part about developing for Apple. Instead of my platform supporting me, I support my platform. It's rear end backwards IMO.

# ? May 24, 2020 15:22

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Yeah it's kinda the nature of the platform, unfortunately. I wish sometimes that they'd at least offer the ability to boot up older versions of the OS for one purpose or another, like even just like spinning up a Corellium-y thing so you can run ancient OSes and play with apps that have since been purged from the App Store. There's definitely a value to looking forward rather than back all the time, but it's a trade off.

# ? May 24, 2020 15:27

lord funk: Feb 16, 2004

ultramiraculous posted:

Yeah it's kinda the nature of the platform, unfortunately. I wish sometimes that they'd at least offer the ability to boot up older versions of the OS for one purpose or another, like even just like spinning up a Corellium-y thing so you can run ancient OSes and play with apps that have since been purged from the App Store. There's definitely a value to looking forward rather than back all the time, but it's a trade off.

Looking forward / looking back are not mutually exclusive. Progress will be made whether apps are purged or not. You could freeze iOS and macOS for 5 years and it would make zero difference on whether new experiences would happen on the platform or not.

All I see is that Apple has zero respect for legacy software. They 100% subscribe to the idea that old == useless. But they forgot that old can equal classic, or vintage, or timeless.

# ? May 24, 2020 15:32

Pulcinella: Feb 15, 2019; Can't post for 11 days!

Has anyone tried to do work in RealityKit? It seems unfinished.

The documentation for ARView mentions things that don�t exist. This init method doesn�t exist. There also is no camera mode property as well.

# ? May 28, 2020 03:58

brand engager: Mar 23, 2011

Anyone familiar with how dSym UUIDs are determined? We use google's firebase for our crash handler and some of the missing debug symbols it shows don't match up with any in the main release. I was thinking maybe builds on different machines would have different symbol UUIDs, so if another dev ran the app in xcode none of their symbols would match what firebase has.

# ? May 28, 2020 16:50

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 07:32

NoDamage: Dec 2, 2000

brand engager posted:

Anyone familiar with how dSym UUIDs are determined? We use google's firebase for our crash handler and some of the missing debug symbols it shows don't match up with any in the main release. I was thinking maybe builds on different machines would have different symbol UUIDs, so if another dev ran the app in xcode none of their symbols would match what firebase has.

If you have Bitcode enabled you need to download the dSYMs from App Store Connect (or Xcode organizer).

# ? Jun 1, 2020 00:28

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

«‹›354 »