[IBDesignable] Opt-out designable and inspectable

[jhersh]

Fixes #460, #510, #520.

[jhersh]

I don't really like this. Also it is not clear if, when imported as a static library via CocoaPods, you can reliably inject a preprocessor define (TTT_NO_DESIGNABLE) before the pod is compiled.

[jhersh]

We could define a TTTAttributedLabel subspec that added a preprocessor define, but it would require those users to switch to that subspec.

[cashmash]

will that be merged?

[jhersh]

@cashmash probably not in this current form; it is problematic especially when used with CocoaPods. I would welcome suggestions here :)

[Fl0p]

@jhersh you can create additional podspec version only for this fix
something like

  "name": "TTTAttributedLabel",
  "version": "1.13.NO_DESIGNABLE",

pointed on this commit

  "source": {
    "git": "https://github.com/TTTAttributedLabel/TTTAttributedLabel.git",
    "commit": "7e62171a114768725dbf99e10cee83f15f3c98e0"
  },

also with preprocessor flag

"xcconfig": {
    "GCC_PREPROCESSOR_DEFINITIONS": "$(inherited) TTT_NO_DESIGNABLE=1"
  },

so enduser just need to install version without designable like this

pod 'TTTAttributedLabel', '1.13.NO_DESIGNABLE'

[jhersh]

That would require us to maintain two releases in parallel, indefinitely, which is really not sustainable. I don't really like the subspec idea for a similar reason -- it would require everyone to switch. Other suggestions are welcome here.

[Fl0p]

@jhersh
Why maintain ?
Just deprecate it and move forward. IOS9 is coming.
Everybody will use next OS versions with Dynamic Framework linking and swift 2.0

Only few retrogrades will support IOS 3.1.1
And there are version them - 1.13.NO_DESIGNABLE
Until they update theirs project to brand new awesome technologies.
If they want more they always can fork and use theirs own fork and commit.

[jhersh]

One of the hallmark features of this project has been backwards compatibility to iOS 4.3. It's true that won't be maintainable forever but I think we should not be so quick to dismiss it :)

[Fl0p]

Ho Ho Ho
Here the solution that will do everything automatically

• You need a custom script (bash, ruby or other)
  • this script should scan ../podfile to !use_frameworks keyword (should not be commented)
  • if not found script should use xcodeproj to add TTT_NO_DESIGNABLE=1 macro to Pods-TTTAttributedLabel target
• than add this script to prepare_command of your spec.

@jhersh thoughts ?

[hagile]

@Fl0p I'm agree with your thoughts. iOS 9 has been already launched by Apple and now its time to update this awesome library for iOS 7 and greater, send all deprecated methods to the hell. Except few companies who're still supporting iOS 3.1. is just too much as there are not enough devices running this version of iOS. @jhersh, you should really mind our comments and do some hallmark changes in this. Where's @mattt, please share your thoughts as well? If one want to support old versions they can definitely fork and commit their own. For that particular reason, we can't miss super awesome features of new iOS. Waiting for a great update on this.

[jhersh]

There is nothing proposed in this change that requires increasing the minimum deployment target or dropping older iOS SDKs. How is that relevant here?

The specific item under discussion is a mechanism that allows the developer to enable or disable TTTAttributedLabel's IB annotations. Enabling or disabling these annotations must be a conscious decision that the developer makes for each of her projects; @Fl0p's script idea, while interesting, takes that choice away from the developer and is too much 'magic' that will be confusing or unclear to the developer.

We are essentially talking about a compile-time switch using one of these mechanisms:

1. Add a #define to your project that changes behavior of the label. This is what is currently implemented here in this PR, but it is problematic in CocoaPods to ensure the define is set before the Pods project is compiled
2. Add a new TTTAttributedLabel subspec, perhaps something like TTTAttributedLabel/NoDesignable, that lets you easily switch in your Podfile between these two configurations
3. Sidestep the problem entirely by installing TTTAttributedLabel as either a dynamic framework or by dragging the files to your project, effectively marking this as 'wontfix'

I am leaning towards 2. Thoughts?

[codecov-io]

Current coverage is 83.24%

Merging designable into master will not effect coverage as of b3cbe57

Coverage Diff

@@            master   designable   diff @@
===========================================
  Files            3            3       
  Stmts         1038         1038       
  Branches         0            0       
  Methods          0            0       
===========================================
  Hit            864          864       
  Partial          0            0       
  Missed         174          174       

Powered by Codecov

[jhersh]

Added subspecs as per 2 above. I think this is a workable option.

[getaaron]

@jhersh I think that's the least objectionable proposal I've seen. Pretty cool - I haven't seen xcconfig used within a subspec before.

[jhersh]

I've been reconsidering this as of late. This entire mess, and its workaround, applies only to people who (1) use TTTAttributedLabel as a static library and (2) attempt to configure a label in IB. I have to imagine that's a vanishingly small section of the userbase, and this workaround is awfully invasive for such a minority use case. There are other, much more stable workarounds, like using a dynamic framework.

I think it might be simpler and cleaner to instead document this limitation and leave it there.