Skip to content

Instantly share code, notes, and snippets.

@landonf

landonf/xcode-gripes.md

Last active August 21, 2020 09:06
Show Gist options
  • Star 20 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save landonf/8203270 to your computer and use it in GitHub Desktop.
Save landonf/8203270 to your computer and use it in GitHub Desktop.
Download ZIP
Every time I hit something that annoys me in Xcode, I add the feature/UX improvement/change I'd like to the list.
Raw
xcode-gripes.md

Xcode Wish List:

Legacy Support

  • Additional optional downloads:
    • Older SDKs, eg, for building ancient projects.
    • Older compilers (for same).
  • Either ship gcc/llvm-gcc or don't. Don't ship clang and call it 'gcc', that just breaks anyone who actually needs GCC and finds your not-gcc in the PATH.

UX

Project/File Navigation

  • Always show the project tree and toolbar in the 'main' project window. HAVE a 'main' project window.
  • Open files in new tabs by default
  • Cleaner tab UI (see IntelliJ/AppCode)
  • "View in Project Tree" from jumpbar w/ right click
  • Allow creating a new file with a minimal UI directly from the project tree
    • Opt-enter or right-click 'add file'
    • Select file type from a pop-over; can use keyboard to type partial template name.
    • Type file name and hit return -- don't use the standard modal 'Save' dialog, just save the file where you'd expect it to be.

Editing UI

  • Allow breaking out of nested palletes into floating palletes.

Snapshots

  • They shouldn't exist.

Project Configuration

  • Key shortcut to display.
  • Display in seperate window by default; don't modally take over the project window.
  • Custom build rules should be shareable across the entire project, not just one target.
  • Build Settings UI
    • Bring back the "Add settings item" buttons in the main UI.
    • Provide contextual menus for functionality stuffed in the "Editor" menu (see Context Menus) below.
    • Move away from a big list of keys and values, design a proper heirarchical UX for project settings, similar to Xcode's preferences, or IntelliJ's setting UI.
      • Provide setting-specific UX; not everything is best expressed as arbitrary string/list entry.
      • Allow searching for settings by changing/highlighting the relevant setting subview.
    • The NSPasteboard data for copied build setting lines should be provided in multiple representations, not just public.utf8-plain-text with internal Xcode markup. One possibility:
      • Simple text containing the setting key and the user visible value, eg, "OTHER_LDFLAGS=-framework XCTest" (UTI public.utf8-plain-text)
      • Rich text that displays the human-readable key and the user-visible value, eg, "Other Linker Flags: -framework XCTest"
      • A custom Xcode UTI that represents the actual entry, and the different values for different configurations.
      • This would replace the current implementation, which inserts particularly non-Mac-like marked up plain text: "//:configuration = Debug OTHER_LDFLAGS = $(inherited) -framework XCTest ..."

Context Menus

  • Put 'Editor' menu items back into the context menus.

Refactoring

  • If indexing needs to complete, display a spinner rather than erroring out.
  • Lighter-weight (non-modal) refactoring UX. It should be fast to change things.

Warnings/Errors

  • Single-key jumping directly to FULL errors displayed in a floating build log that always shows the latest build log.
  • Don't display resource warnings, eg, 'Missing "Default-568h@2x.png" launch image' at the same level as compiler/build warnings.

Inline Documentation

  • Open documenation in the documentation browser, not a popover.

Documentation Browser

  • Restore the 'Overview' section (Xcode <= 4). Displayed:
    • Inherits from
    • Conformed to
    • Containing framework
    • Availability (eg, 10.5 and later)
    • Declared in (the header(s) the type is declared in)
    • Companion guides (eg, top-level programming guides).
    • Related sample code
  • Move document index to the right, always display by default. There's more room on the right margin.
  • Show full search results by default (not the floating results) to allow easier selection (see Xcode <= 4).
  • Search results should be displayed persistently to allow easier browsing (see Xcode <= 4).
  • Display docsets on the left by default, expanded to current item.
  • Use standard forward/backward buttons. What are those things?

Functionality Improvements

Scriptability

  • Re-implement all of the no-op'd methods from Xcode3's applescript dictionary.
  • Correctly update the UI when data structures are updated from AppleScript (eg, setting a build phase script's contents doesn't update the UI).

Compilation

  • Improved error reporting
    • Show FULL compiler errors, inline (see Warnings/Errors section above).
    • Always select and display the last build log by default when switching to the build log UI.
    • Hide older build logs. Nobody cares.
    • Provide a build output window or section of the display (see Xcode <= 3, IntelliJ), rather than stuffing it modally in the main project window.
    • Allow selecting of text within the summarized error messages. In Xcode 5.x, it appears that one can only select and copy the full line. To copy partial text, it's necessary to expand the full error message.

Templates

  • In-Xcode UI for defining/modifying file and project templates
  • Project Templates
    • Re-introduce non-storyboard templates. Storyboards are stupid, and taking away the non-storyboard templates was stupider.
    • iOS Static Frameworks

Code Style

  • Allow defining custom code style (see IntelliJ)
    • Including disabling indenting of top-level C++ namespaces
    • Allow specifying more whitespace details.

Code Completion

  • While typing, completion should display the text I've typed (including capitalization), NOT the completion it thinks its found. Eg, if I'm typing "Session" and Xcode has found "session", "_S_ession" should still be displayed until I choose to select the auto-completion.
  • Don't automatically complete a function(arguments) if an argument list already exists. (eg, fo(already, has, args));
  • Provide better auto-fix suggestions; eg:
    • Add missing required protocol methods.
    • Create missing ivars.
  • Provide a simple key-combo for auto-fix + code generation.

Code Signing

  • Configuration.

    • Signing identity and provisioning profiles identifiers do not belong in the target settings. This makes it difficult to share projects across organizations and sometimes even between developers within an organization, due to mismatches in the require identities and SCM churn as each developer modifies the project locally.
    • Target settings should only specify the capabilities required for the target's code to function -- iCloud, XPC, In-App purchasing, etc.
    • The actual signing certificate, key, and provisioning profile should be selectable at build time, by the developer, without changing any project settings.
    • Appropriate certificates, keys, and provisioning profiles should be automatically matched or generated, using a combination of matching conditions supplied by the build target (which defines requirements) and supplied by the user at build time (who defines the deployment target). For example, the aggregate conditions used to select keying material would be:
      • Certificate Common Name (eg, similar to how it's done now: Developer ID: *) (Deployment Condition)
      • App ID (Deployment Condition)
      • Functionality: (Target Condition)
        • iCloud
        • XPC
        • Sandbox exceptions
        • etc.
      • Deployment Target: (Deployment Condition)
        • iOS: AppStore, iAdHoc, Enterprise, Development
        • Mac: AppStore, DeveloperID, Development
    • Xcode's matching heuristics should take all of these requirements into account, and match across certificates, private keys, and provisioning profiles. Only a full set of valid keying/certificate material should be allowed to satisfy the requirements, rather than than the current situation, where Xcode simply errors out when conflicts are found between the selected certificate, provisioning profile, and application.

  • Certificate Management

    • This should be performed automatically, based on the capability requirements and deployment target specified by the user.
    • Provisioning profiles should be requested automatically. Users should not be requried to manually refresh in Preferences -> Accounts -> Apple IDs -> [Account] -> View Details while waiting for a provisioning profile.

Target Definitions

  • Multi-Platform Builds
    • Automate handling of essentially duplicated targets across sim/ios/mac. It should be possible to build a single 'target' for multiple platforms without duplicating all the target settings across each platform.

Unit Testing

  • Auto-generatation of XCTestCase for a given class.
    • Create the file automatically
    • Add to appropriate target automatically
    • #import the target class's header at the top of the file.
    • Make this accessible from the autocomplete keystroke.
  • Allow running a test, or multiple tests, simply by selecting the source files or ObjC class names and choosing 'Test' from a context menu.
  • Test errors should disappear if a rebuild fails.
  • XCTAssertEqual's should either cast, or provide an actually useful message when equality checking fails due to differing types.

Interface Builder

  • Display in seperate window by default
  • Use floating palettes instead of embedded palettes.
  • Re-introduce IB plugins for Mac OS X
  • Introduce IB plugins for iOS.

Embedded Tools

  • Add support for filing radars directly from Xcode.
  • External 'shell' applications for embedded tools; allow for both in-IDE editing and external editing in a dedicated app:
    • Property List Editor
    • Interface Builder

Bundled Tools

  • Provide a standalone Radar application.
  • Update command line tools:
    • Subversion binary is older than dirt.
  • Expose "Bundled" Tools in /Applications (eg Instruments).
  • Support for automatically downloading 'extra' tools
    • Extra:
      • Instruments
      • File Merge
      • IORegistryExplorer
    • Legacy:
      • Property List Editor
      • ...

SCM

  • Git integration bugs
    • Xcode always adds 'build' directories to git if you choose to create a git repository upon project creation.

Debugging

  • Hide CPU+Memory Stats by default. Those have nothing to do with debugging.
  • Always show full backtrace. In fact, get rid of summary backtraces entirely.
  • Show register state by default
    • Ideally in a compact/seperate/liftable window.
    • Once displayed, don't collapse register state after stepi/stepi.
  • Show the actual crashing instruction, even if no code is available, rather than the first frame with user code.
  • Easy and fast switching between assembly and source views.
  • Allow for easy lifting of the debugger into seperate window.
  • Always expand debugger on a breakpoint (eg, a unit test breakpoint).
  • Always display the LLDB console if it was previously displayed.
  • Create a shorter LLDB command line syntax for human beings.

Command Line

  • xcodebuild should always use the Xcode project default workspace – xcodebuild doesn't use a workspace by default, Xcode does. Leads to confusion and inconsistent builds. (from @schwa).
  • Simplify running the compilers for available targets by providing classic 'target-triplet' compiler wrappers (eg, arm64-apple-ios-clang and apple-ios-clang)
    • Provide both arch-specific and arch-non-specific wrappers.
    • Use xcrun to fetch paths.
    • Automatically set -isysroot and -arch flags.
@schwa
Copy link

schwa commented Jan 7, 2014

Add to your command-line section: "Always use the Xcode project default workspace"

xcodebuild doesn't use a workspace by default, Xcode does. Can lead to much confusion and inconsistent builds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment