|
Doctor w-rw-rw- posted:Sounds like the pretty standard complaints (which I share). Personally, I think that CocoaPods' approach to compilation is not the best and IMO iOS framework support makes me want to write a new build system that resembles maven's versioning/artifact system, but with a way simpler compile/configuration system (Xcode appears to support external build systems). Do you or others have the bandwidth to spare? Sounds like fun to me! What do you like about maven? I know nothing about it, so "everything, go rtfm" is an entirely reasonable response.
|
#
?
Oct 1, 2014 08:23
|
|
|
|
| # ? Jun 5, 2024 02:48 |
|
|
pokeyman posted:Sounds like fun to me! What do you like about maven? I know nothing about it, so "everything, go rtfm" is an entirely reasonable response. Versioning: Packages are identified uniquely by 1) groupId 2) artifactId 3) version 4) Optionally, "-SNAPSHOT" to signify it's built from a snapshot (i.e. not a tagged version), or, roughly: reverse.dns.packagename-1.0.0[-SNAPSHOT].{jar,pom} - where .pom is the metadata and .jar is the compiled stuff (with a manifest inside, but that's a fairly standard Java JAR). So: se.atoulou.foobar.baz-1.3.3 would correspond to a groupId of "se.atoulou.foobar", and an artifactId of "baz", version 1.3.3, and this would uniquely identify a published artifact. So that's not terribly hard, but the key idea for *that* is that it makes namespacing very clean and easy. Also, it tends not to need to rely solely on a megabig Specs repo like CocoaPods does, but in practice, a lot of popular packages are pretty easy to find. But that's more of an ecosystem thing (running your own repositories) than an inherent feature of Maven, because CocoaPods can do that too, albeit without namespacing. Note that while these maven artifact identifiers typically share the names of the Java packages they represent, but there is no requirement to do so. Haven't played with Swift enough to know how modules work, or if reverse-DNS namespacing is sensible versus very coarse name-based namespacing (if it results in SE_ATOULOUSE_FOOBAR_ClassName, that's obviously very lovely) Compilation Version is a required component of the package identifier. This is not so much a practical thing (having to figure out what the latest version is by sorting non-numeric versions, i.e. 1.0.0rc2) as it is an emphasis on deterministic, repeatable builds. You declared a dependency on package X while it was at version 5? You did so explicitly; that exact version will also be downloaded now even if an artifact for a newer version was published to the public repository. To put further emphasis on it, the key idea mentioned above is reproducible builds. This is where the solution can't map directly to ideas in Maven, because (without crazy plugins), Java is a lot simpler to compile than C/C++/ObjC/ObjC++ family objects. So to speak in general platitudes, here are some general ideas that are swimming around in my head tonight: Taxonomy (maybe): Modules, source groups, source files Configuration: a source file (swift? python? ..heavily macro'd ObjC?) Shim modules are created for system frameworks (at some point) Xcodeproj files that are structured fairly conventionally can be processed to create approximate project files for this hypothetical build system. Builds
Build Configurations
Source Groups
CocoaPods Compatibility
Build Stages
I'm positive I missed something (like extensibility, provisions for Xcode compatibility / debugging, header search paths, and shims to cover non-framework system libraries - i.e. zlib, cross-compilation support assuming clang+an ObjC runtime+san eenvironment is available), in part because of a nagging feeling I have that I was about to type something and that idea escaping me. EDIT(1:55AM): fixed errors, misc. additions EDIT(2:03AM): more misc. additions, spelling ...Thoughts? Doctor w-rw-rw- fucked around with this message at 10:03 on Oct 1, 2014 |
|
#
?
Oct 1, 2014 09:46
|
|
|
i think LLVM has whole-program IR opt passes, so that wouldn't work well with separate file compilation
|
|
#
?
Oct 1, 2014 10:05
|
|
|
Anyone have any experience of whether an upgrade to Yosemite will break a C++ centric development environment? I'm using brew for some dependency management and clang/libc++ for building. I recall that when Mavericks came out, it caused me a bunch of grief with having to recompile a bunch of dependencies (but that was due to apple making the switch to libc++ with Xcode 5 iirc which caused a bunch of precompiled dependencies served by brew and mac ports to break).
|
|
#
?
Oct 1, 2014 12:23
|
|
|
Plorkyeran posted:Installing the second GM seed (which became the final release) on top of the first GM seed was tricky, but upgrading GM1 -> 10.9.1 worked fine. To my knowledge, it wasn't an official GM seed 2. Instead, the build number of the GM seed changed from 13A598 to 13A603 without notice and with no upgrade mechanism. I don't have development access to a second machine, so I'm hesitant to install because of that stealth update, which contained changes to Mail-related files.
|
|
#
?
Oct 1, 2014 17:35
|
|
|
Doctor w-rw-rw- posted:I half-expected a certain solution to appear by now, which it hasn't. Is this some proprietary build system you've experienced before? Doctor w-rw-rw- posted:Good stuff When you have a few minutes, check out the clang modules documentation. If module maps are usable now (they were restricted to system frameworks and might still be) then that might be a solid basis for a new build tool. Also note the parts about exposing system libraries as modules. The only missing part of your story to me is how a new build tool interacts with Xcode. How does that work with Maven? Does Eclipse know about Maven projects?
|
|
#
?
Oct 1, 2014 20:13
|
|
|
pokeyman posted:Is this some proprietary build system you've experienced before? pokeyman posted:When you have a few minutes, check out the clang modules documentation. If module maps are usable now (they were restricted to system frameworks and might still be) then that might be a solid basis for a new build tool. Also note the parts about exposing system libraries as modules. Eclipse knows about Maven projects, yeah. Before good support for it was integrated, though, the tools dealt by generating the relevant project files (i.e. .project and .classpath), which to some degree, I think they still do. But then again, Java compilation is a lot simpler than native code, so I'd hesitate to try to resemble it rather than do what seems right. I thought about it a bit, and I think generating an xcodeproj, CMake style, with a run script phase that invokes the build system is the most realistic option. That said, CMake's project generation blows, because it's all very flat, and is basically just there to produce references to files, rather than actually organizing them into logical groups -- so at least respecting the module/source group organization would seem to make sense. Maybe custom tags could even help build multiple views of the source, organized differently in different xcodeproj groups. Hmm. Getting rid of the idea of "source groups" and having modules and source files be the only elements in the tree might be compelling, but I have a nagging suspicion that there's an enormous pitfall I'm not noticing in both cases. Producing module files seems like it would be easy enough, as well as producing shims for dependencies, though. Crazy idea: Build the build system like a library (like clang) or like a daemon (gocode, though that's more of an autocompletion thing) so it can be implemented by an IDE (or "traditional" text editor) In terms of actually building something like this, I think step one would be writing a hypothetical configuration file for a simple project, then building a parser to create the appropriate data structure, then going down the list of phases (preprocess/validate/compile/test/package) until you have a dead-simple Example.framework built from Example.{m,h} and FooBar.{mm,h}. Is there a good place to take further discussion of this? project.log maybe? Doctor w-rw-rw- fucked around with this message at 05:22 on Oct 2, 2014 |
|
#
?
Oct 2, 2014 05:18
|
|
|
Doctor w-rw-rw- posted:Is there a good place to take further discussion of this? project.log maybe? I was going to suggest the very thing once you'd replied to my questions. Let's meet over there.
|
|
#
?
Oct 2, 2014 05:48
|
|
|
Doctor w-rw-rw- posted:It wasn't release quality at the time, and had some baggage. I hear it's gone back to the drawing board. It's not secret but it hasn't been announced, so I didn't refer to it by name. You sure do a lotta talkin buddy 
|
|
#
?
Oct 2, 2014 06:20
|
|
|
shodanjr_gr posted:Anyone have any experience of whether an upgrade to Yosemite will break a C++ centric development environment? I'm using brew for some dependency management and clang/libc++ for building. It won't be Yosemite that breaks such an environment, it will be the toolchain (compiler et al) or the SDK. The former comes from the DevTools and the latter is included with the DevTools, whether you're using the Command-Line Tools package or Xcode. Your best bet to find out whether Xcode 6 or 6.1 breaks you is to just try it: Download the disk image version from the developer web site, install it off to the side somewhere (multiple Xcode installations can coexist on one system), use "sudo xcode-select -switch" to point your command-line use at the tools in the newly-added Xcode, and try it out. Since Xcode 6.0.1 went to the App Store approximately when iOS 8 was released, it's a fair bet that any mainstream dependencies have already been fixed. (And they should've been fixed soon after WWDC build or another beta build broke them, if their maintainers were on the ball.) Protip: DO NOT install some other Python in /System/Library/Frameworks. Replacing the system Python will break LLDB, and hence Xcode. I don't know what does this but something does and it's bad. /System (and /usr outside of /usr/local) should be treated as inviolate. I'm pretty sure brew and MacPorts are fine here, but I just felt a warning was in order.
|
|
#
?
Oct 2, 2014 07:22
|
|
|
Doctor w-rw-rw- posted:I thought about it a bit, and I think generating an xcodeproj, CMake style, with a run script phase that invokes the build system You probably don't want to hear this, but the only legit, supported, and safe way to generate an Xcode project is to use Xcode. Something that purports to be an Xcode project but is generated by some other tool can easily get something wrong, possibly something subtle, in a way that breaks either now or in the future. For example, if a project claims to be format v43, Xcode may think it knows how to upgrade it to v46, but you may not know exactly how v43 format files were written or what bugs Xcode might be working around in that, and wind up with a non-working file. And so on.
|
|
#
?
Oct 2, 2014 07:29
|
|
|
eschaton posted:You probably don't want to hear this, but the only legit, supported, and safe way to generate an Xcode project is to use Xcode. Something that purports to be an Xcode project but is generated by some other tool can easily get something wrong, possibly something subtle, in a way that breaks either now or in the future. You may not want to hear this, but I hope I'm being fair/reasonable: We're already well into the territory where Apple and Xcode isn't meeting and *can't* meet developers' needs, and we've been there for some time. There is no legit/supported/safe way to manage project dependency resolution and download, and much of the externally-developed tooling around Xcode has been built only after fighting Xcode first, and tends to fall over often. The first-party solutions that are provided for other parts of the developer experience - for example, OS X Server's Xcode service - are grossly inadequate for practical use. Even with improvement on that front, it's impossible to construct any kind of long-term plans that involve them, because Apple's style is to hide its progress from the public eye. That works for products; it doesn't work for developer infrastructure. The yearly post-WWDC rush to fill in the holes has often been exhausting and inconvenient. For some kinds of projects, "Update project settings" is simply a seasonal occurrence that you learn to ignore or go through the motions to fix every time it comes up. Apple really needs to open Xcode up. Apple alone is not in a good position to create the best developer tools to make Apple platforms the best development environment, despite an army of people outside who want to help it get there. While in many respects it's clearly done a good job overall on creating an IDE, its success in that very specific metric (best developer tools for Apple platforms) is owed entirely to the fact that they are the only source of supported tools for developing for Apple systems. And though I'll be first to say that Xcode is a very pleasant IDE to code with, and my favorite for native dev over Eclipse, IDEA, Sublime Text, and even my heavily-customized vim configuration - the moment anyone tries to do anything Xcode itself doesn't do, there are no assurances of safety, support, or that it'll work when the next big thing comes along (even when it's actually great: this only came up because we really want to use shared libraries and Swift). So...Xcode isn't open-source or have documented extension points (despite supporting plugins built from extremely-unsupported reverse-engineering), and CocoaPods is the closest we have to a stable tool for managing dependency resolution / download. Even so, I've spent hours just today fighting CocoaPods' irritating XML<->ASCII Plist mishandling, poor handling of source control integration in both CocoaPods and Xcode (for very different problems), and Xcode failing to build a release target for device, because the it couldn't find a armv7 architecture for XCTest in the simulator for the test/debug target I wasn't even compiling (but erroring out from missing symbols regardless). So the dilemma is this: There needs to be a quality build system that accounts for the modern realities of iOS development, but to do so, it has to both supplant Xcode and embrace it simultaneously. As far as people who don't have source-level access to IDEFoundation or DVTFoundation or whatever private frameworks Xcode uses are concerned, the build system is inextricably glued to the IDE-generated, unspecified, and non-extensible project representation. This makes developing for iOS from Xcode on an OS X computer hard for many people who, given the chance, could both benefit from and contribute meaningfully back to remedying that. There's also the fact that many actually DO want to use Xcode to build projects for pretty much any C/C++ code (me being one of them), even if it's not just intended for iOS. The best bet at this moment, I think, is CMake - and its integration with IDEs is currently pretty darn horrible. The story for compiling C++ is currently "Use Visual Studio for Windows, Xcode for OS X, or just avoid Xcode and use autoconf+Makefiles/CMake/gyp/etc.". With clang-cl showing a lot of promise for Windows-native linking - having a good story for pulling in native dependencies, juggling the kind of configuration you need for compiling against multiple different target platforms, and having quality IDE integration is needed more than ever. And none of the tools that are popping up that handle C/C++ dependencies in their own ways has support for Xcode project that's anywhere close to acceptable, because Xcode will always, always do it better. (By the way, I don't know if Apple is paying attention to Android's tooling, but switching from custom ant scripts to a gradle-based platform (which integrates with maven artifacts) has been a godsend.) So basically, what I'm saying is - what other options do we have? EDIT: drat, I'm doing a crapton of writing these past couple of nights. Sorry guys. Hope you don't mind too much. EDIT: Clarity. Doctor w-rw-rw- fucked around with this message at 09:13 on Oct 2, 2014 |
|
#
?
Oct 2, 2014 08:48
|
|
|
Doctor w-rw-rw- posted:EDIT: drat, I'm doing a crapton of writing these past couple of nights. Sorry guys. Hope you don't mind too much. Not at all! This is the only place where I get to hear about this stuff.
|
|
#
?
Oct 2, 2014 16:39
|
|
|
How do you conditionally add a framework? The CoreAudioKit framework is not supported on the Simulator, so it fails if you try and build when targeting it. Big thanks, CoreAudio team, for another stellar framework experience!
|
|
#
?
Oct 2, 2014 18:38
|
|
|
Do people still use the simulator? I haven't used it in ages. It's so slow to start up that launching on the device is faster now. Of course, I've been doing mainly game development lately, where the simulator is useless.
|
|
#
?
Oct 2, 2014 20:02
|
|
|
Doc Block posted:Do people still use the simulator? I haven't used it in ages. It's so slow to start up that launching on the device is faster now. Really? I'm exactly the opposite. Waiting for files to copy through the USB cable, launch times slower, all to check that my tableview has the right background color. I obviously use the device for functionality testing, but for UI stuff I spend a ton of time flipping through the simulator.
|
|
#
?
Oct 2, 2014 20:15
|
|
|
Can anyone recommend a good primer for how Apple approaches the screen sizes of various iOS devices at this point? I've been digging through some Oreilly books and they all just kinda skirt around a bit and id just like something that covers what I should be doing to address all the various sizes and whatnot. I know it's vague but it's something I haven't been able to find a solid (and relatively recent) update on. Spritekit specifically.
|
|
#
?
Oct 2, 2014 20:30
|
|
|
lord funk posted:Really? I'm exactly the opposite. Waiting for files to copy through the USB cable, launch times slower, all to check that my tableview has the right background color. I obviously use the device for functionality testing, but for UI stuff I spend a ton of time flipping through the simulator. Same here. Also, 10 days of waiting for an update to even get into review. Anyone else stuck in purgatory because of iOS8? Doh004 fucked around with this message at 20:43 on Oct 2, 2014 |
|
#
?
Oct 2, 2014 20:40
|
|
|
The simulator does take forever to start, but why does that matter? Just leave it running all day.
|
|
#
?
Oct 2, 2014 20:45
|
|
|
Doh004 posted:Same here. Word is that post-iOS 8, reviews are taking a minimum of 8 days to start (up to double that expected)
|
|
#
?
Oct 2, 2014 20:46
|
|
|
Doh004 posted:Also, 10 days of waiting for an update to even get into review. Anyone else stuck in purgatory because of iOS8? For a concrete data point: Awful spent ten days "Waiting for Review", then was "Metadata Rejected" on September 29, then "In Review" September 30, and that's where it sits right now.
|
|
#
?
Oct 2, 2014 20:53
|
|
|
drat, aight we can all complain in solidarity 
|
|
#
?
Oct 2, 2014 20:55
|
|
|
lord funk posted:Really? I'm exactly the opposite. Waiting for files to copy through the USB cable, launch times slower, all to check that my tableview has the right background color. I obviously use the device for functionality testing, but for UI stuff I spend a ton of time flipping through the simulator. The simulator is too slow for testing games, because the GPU is simulated via software rendering. Game programming forums are full of "OMG my simple 2D game is only hitting 20 FPS, what am I doing wrong?" posts, where the the poster was using the simulator, and the answer is always to try it on the device and see how it runs. "Oh wow, it runs at 60 FPS when I run it on the device!" Seriously, I've experienced this myself, where running my game in the simulator is slow but running it on an actual device is buttery smooth. Plorkyeran posted:The simulator does take forever to start, but why does that matter? Just leave it running all day. Because I have a bad habit where I mindlessly mash CMD-Q the instant I'm done testing on the simulator and want to switch back to Xcode.
|
|
#
?
Oct 2, 2014 21:23
|
|
|
One option I use is the xcodeproj and xcodeworkspace aren't even in source control. We use a modular system of dependency management via JSON files and then premake builds the project files right before Xcode opens. One benefit is it frees you to refactor class names at the drop of a hat across project/platforms since you just rerun premake and continue coding.
|
|
#
?
Oct 2, 2014 22:49
|
|
|
lord funk posted:How do you conditionally add a framework? The CoreAudioKit framework is not supported on the Simulator, so it fails if you try and build when targeting it. In your "Link Binary with Frameworks" step there is a little option to toggle between Optional and Required. That Might be what you are looking for.
|
|
#
?
Oct 3, 2014 02:46
|
|
|
Walked posted:Can anyone recommend a good primer for how Apple approaches the screen sizes of various iOS devices at this point? Well, for regular UI stuff you use autolayout and size classes. For SpriteKit you're pretty much on your own, though your game's UI can be done with UIKit and so you can use autolayout and size classes for that part of it. For Cocos2D (Objective-C/Swift) you have the option of using a fixed "screen" size based on points that that is the same across all devices and completely divorced from the pixel size of the screen, where iPad assets are treated as @3x and iPad retina assets are treated as @4x assets.
|
|
#
?
Oct 3, 2014 05:39
|
|
|
pokeyman posted:I was going to suggest the very thing once you'd replied to my questions. Let's meet over there. Thread posted.
|
|
#
?
Oct 3, 2014 06:05
|
|
|
Doh004 posted:Same here.   Plus they're asking us to resubmit our cryptography export compliance documents, and add a privacy policy URL And of course Xcode 6 broke binary submission again and I had to downgrade to 5.1.1
|
|
#
?
Oct 3, 2014 10:10
|
|
|
Kallikrates posted:In your "Link Binary with Frameworks" step there is a little option to toggle between Optional and Required. That Might be what you are looking for. It didn't do it for me. The docs are a little vague in that they say the framework won't be loaded unless it's used, but it prevents my target from building if it is added to the target. So I want to conditionally add it to the target if building for iOS devices, and not if building for the simulator.
|
|
#
?
Oct 3, 2014 14:56
|
|
|
You could add the CoreAudio dependency in the build settings as a custom linker command or whatever. You should be able to go to the build setting that lets you add custom command line options for the linker, drill down into the separate build configurations, and drill down into each build configuration until you see something about build for iOS devices and add "-framework CoreAudio" Not at my computer right now so I'm just going off of memory, so some of the details might not be exactly right. You'll probably also have to do the same for the preprocessor so it'll know where to find the CoreAudio headers.
|
|
#
?
Oct 3, 2014 15:58
|
|
|
Anyone have any ideas on workflow improvements to working with multiple teams? We have a couple team accounts Dev Enterprise Production Up till Xcode6 and app extensions, we could set 'None' on the teams page and code signing would work fine with whatever profiles, bundleID's, and signing certs and entitlements. Something new in Xcode6 or someway we have profiles setup since then, when someone selects a Team (say to build a target for release, or CI for enterprise) Xcode goes and changes CODE_SIGN_IDENTITY settings throughout the project, always to developer, and breaks parts of our build system. We feel the team setting shouldn't affect the CODE_SIGN_IDENTITY, especially since in the 80% case it signs fine with "None".
|
|
#
?
Oct 3, 2014 16:36
|
|
|
Oh god my old code does not work well in the iPhone 6 and 6+. Why was (am) I so lovely two years ago!
|
|
#
?
Oct 3, 2014 20:49
|
|
|
So I found the source of one of my build problems! DerivedData isn't the only directory that can have stale files -- there's a folder somewhere in /var called SharedPrecompiledHeaders that you might have to delete, too. You can find that directory by running this in your project directory: echo `xcodebuild -showBuildSettings 2> /dev/null | grep CACHE_ROOT | cut -d= -f2 | tr -d ' '`/SharedPrecompiledHeaders EDIT: it doesn't always exist, it seems. But if it gets stale, that's how you'll find it. EDIT 2: Clearing that fixed my problem /once/. Why, I don't know, because a couple of hours later, the problem is back, but there's no cache. Argh. Doctor w-rw-rw- fucked around with this message at 01:02 on Oct 4, 2014 |
|
#
?
Oct 3, 2014 22:33
|
|
|
Doctor w-rw-rw- posted:So I found the source of one of my build problems! DerivedData isn't the only directory that can have stale files -- there's a folder somewhere in /var called SharedPrecompiledHeaders that you might have to delete, too. You can find that directory by running this in your project directory: quote:% xcodebuild -showBuildSettings DIDN'T TELL ME poo poo!
|
|
#
?
Oct 3, 2014 23:40
|
|
|
*sigh*just when I felt like I was starting to understand Autolayout. I have a screen designed in IB with the size set to hAny wAny, as per all the new "adaptive design" hotness I have been reading about. I futzed about with constraints and finally had it completely pristine - nary a Warning to be found. Running it on all the form factors present in the simulator it works great. Everything resizes based on the display size, etc. One of the fields on the form is a text field and it's near the bottom - so I have the (completely common) problem of getting the field to scroll up into view when the keyboard covers it. And thus my odyssey began... I added a UIScrollView and a UIView in that as a container, per several tutorials I have seen on the subject. Moved all my controls inside the UIView and fired it up in the sim to see what would happen. Predictably, nothing resizes itself based on the display size. You can simply scroll further to the right to see anything too wide to fit the display. So I go back and start adding constraints. A button at the top. A centered label. A centered text field below that. Good good. No issue. BUT. Below that I have a set of two labels on top of two text fields, which I have nested in views so I can align them accordingly. As soon as I apply ANY constraint to ANYTHING in that set of subviews, I get a shitload of warnings about ambiguous view sizes, including the button, centered label and centered text field I mentioned above, which were apparently fine a few seconds ago. No matter how many constraints I go on adding, the warnings never disappear. How can a horizontal position be ambiguous when I have specified width AND told it to center in a superview? UGH. All I want is: My content to resize itself and maintain distances from EACH OTHER based on the screen size. NO horizontal scrolling at all, and the ability to scroll up automagically when the keyboard appears. Can someone give me some sort of idea how to do this? I did manage to disallow horizontal scrolling by checking the device width and setting the UIScrollView's contentSize to that. Other than that - I am lost in a hell of Autolayout warnings. SNED HLEP.
|
|
#
?
Oct 5, 2014 18:27
|
|
|
HaB posted:How can a horizontal position be ambiguous when I have specified width AND told it to center in a superview? This is mostly a stab in the dark, but maybe it's because scroll views under Auto Layout calculate their contentSize based on the constraints of its subviews, so a centerX constraint will fail when the width isn't known. Does it work without warnings when you actually run the app? If so, you'll need to add some placeholder constraints or set some intrinsic sizes to avoid the warnings in IB.
|
|
#
?
Oct 5, 2014 20:09
|
|
|
What the hell, our privacy policy doesn't have a direct URL (it's accessible on our root page, which is the URL provided in the metadata, by clicking a link). Our app has been on the app store for two years now, and now they're rejecting it because some new policy when nothing has changed. Trying to argue with them that our privacy policy is right there and nothing has changed, but I feel like I'm gonna just need to push something to have a stupid direct URL.
|
|
#
?
Oct 6, 2014 03:30
|
|
|
Doh004 posted:What the hell, our privacy policy doesn't have a direct URL (it's accessible on our root page, which is the URL provided in the metadata, by clicking a link). Where does the link point to then?
|
|
#
?
Oct 6, 2014 03:54
|
|
|
pokeyman posted:Where does the link point to then? Our root domain (https://www.relsci.com). It's in our Terms & Conditions modal. That said, they just approved the application so it looks like my complaining worked. Hooray Apple!
|
|
#
?
Oct 6, 2014 04:04
|
|
|
|
| # ? Jun 5, 2024 02:48 |
|
|
I don't understand how large companies deal with the asinine device limit... or is it just that they use enterprise distribution? I have a 6 ++ (it's huge) and we can't test on it because our device list is full and can't be reset yet. Seriously Apple, we're not trying to bypass the app store and sell unapproved apps just because we'd like to have more than 100 devices registered. Also now that I'm in SF anyone know of an active NSCoder night or other meet ups?
|
|
#
?
Oct 7, 2014 06:34
|
|