@NathanWalker Whenever possible, I believe we should revert this one as it's unsafe.
There is the case that corner radius will cause unexpected results if children are added to view "before" view shadow is applied for some reason, as children layers will be appended to parent sublayers.
I have thought of a good way to solve box shadow problems and maintain a good performance at the same time.

@CatchABus if of any interest to you I had done this in another cross platform framework Titanium. I can fins the code if you need

@CatchABus if of any interest to you I had done this in another cross platform framework Titanium. I can fins the code if you need

Sure! It could be a good addition!

Note: I tend to think that using main layer with masksToBounds and clipsToBounds for shadows will keep causing trouble in the future. Maybe we should also consider the use of a sublayer for shadows as one solution?

@CatchABus it s all here https://github.com/Akylas/titanium_mobile/blob/master/iphone/Classes/TiUIView.m#L610= . If you have any question ping me on discord.
BTW a lot of things can be taken from there. I had animation working for almost anything!

Note: I tend to think that using main layer with masksToBounds and clipsToBounds for shadows will keep causing trouble in the future. Maybe we should also consider the use of a sublayer for shadows as one solution?

I agree - I was working on the initial box-shadow implementation and had tinkered with the idea of using proper sublayers for shadows - allowing stacking multiple shadows etc, however there was a major roadblock (fixable I would imagine, but still was major)...

Given an ios view, you can add as many subviews as you want, however you cannot move them behind the parent view, only above it (at least if I remember correctly, been a while...) - which meant we couldn't easily add a shadow layer to existing views and move them behind the view. The approach I was playing around with was adding an extra parent view to hold the original view + the shadow layers, but managing that was kinda tricky as core View handling is set up to handle the root view and not anything above.

Wrapping every view in a extra view seemed like a bad solution, as it would double the number of views rendered even if most of them don't render a shadow.

Ideally the following structure could work:

  View
    -> nativeView (UIView or whatever)

  View with shadow
    -> decorView
       -> nativeView (UIView or whatever)
       -> shadowLayer1
       -> shadowLayer2
       -> etc.

Note: I tend to think that using main layer with masksToBounds and clipsToBounds for shadows will keep causing trouble in the future. Maybe we should also consider the use of a sublayer for shadows as one solution?

I agree - I was working on the initial box-shadow implementation and had tinkered with the idea of using proper sublayers for shadows - allowing stacking multiple shadows etc, however there was a major roadblock (fixable I would imagine, but still was major)...

Given an ios view, you can add as many subviews as you want, however you cannot move them behind the parent view, only above it (at least if I remember correctly, been a while...) - which meant we couldn't easily add a shadow layer to existing views and move them behind the view. The approach I was playing around with was adding an extra parent view to hold the original view + the shadow layers, but managing that was kinda tricky as core View handling is set up to handle the root view and not anything above.

Wrapping every view in a extra view seemed like a bad solution, as it would double the number of views rendered even if most of them don't render a shadow.

Ideally the following structure could work:

  View
    -> nativeView (UIView or whatever)

  View with shadow
    -> decorView
       -> nativeView (UIView or whatever)
       -> shadowLayer1
       -> shadowLayer2
       -> etc.

Perhaps, this issue gets solved using insertSublayerAtIndex or setting layer zPosition to negative value (default is 0 for all layers).
I'm using those in my neumorphism shadow plugin.

Note: I tend to think that using main layer with masksToBounds and clipsToBounds for shadows will keep causing trouble in the future. Maybe we should also consider the use of a sublayer for shadows as one solution?

I agree - I was working on the initial box-shadow implementation and had tinkered with the idea of using proper sublayers for shadows - allowing stacking multiple shadows etc, however there was a major roadblock (fixable I would imagine, but still was major)...
Given an ios view, you can add as many subviews as you want, however you cannot move them behind the parent view, only above it (at least if I remember correctly, been a while...) - which meant we couldn't easily add a shadow layer to existing views and move them behind the view. The approach I was playing around with was adding an extra parent view to hold the original view + the shadow layers, but managing that was kinda tricky as core View handling is set up to handle the root view and not anything above.
Wrapping every view in a extra view seemed like a bad solution, as it would double the number of views rendered even if most of them don't render a shadow.
Ideally the following structure could work:

  View
    -> nativeView (UIView or whatever)

  View with shadow
    -> decorView
       -> nativeView (UIView or whatever)
       -> shadowLayer1
       -> shadowLayer2
       -> etc.

Perhaps, this issue gets solved using insertSublayerAtIndex or setting layer zPosition to negative value (default is 0 for all layers). I'm using those in my neumorphism shadow plugin.

I'm not sure - I'm pretty sure I tried every possible combination, and could not move my shadow layer below the actual view - inserting it at various indices or zPositions, was always above the view. But if that works, that'd be perfect 👍

@rigor789 I'm not sure if I understood correctly but I have this plugin for neumorphism styling: https://github.com/CatchABus/nativescript-plugins/tree/master/packages/ui-neumorphiclayout
It uses 2 sublayers because support for 2 different shadows is needed. So far, I have nested children inside those views without problems.
Maybe, this concept could serve for adding multiple shadows support to NS.

@CatchABus I just remembered - I never deleted the tests I did here (they are ignored, as we return early):

removing the early return yields the following:

With some logging - here are the resulting layers:

Haven't had a closer look at your plugin, or what it does differently - but if you want you can try the above:

• run the toolbox app -> box-shadow -> toggle solid background -> apply shadow
• comment out the return in the native-helper.ios.ts and let the test logic run
• make any adjustments in there to see if there's a way to move that shadow layer below the actual view...

I guess the difference is that in your plugin you have a fillColor property - and not the regular backgroundColor/backgroundImage I guess, so you have more control of the drawing there?

@CatchABus I just remembered - I never deleted the tests I did here (they are ignored, as we return early):

NativeScript/packages/core/utils/native-helper.ios.ts

Lines 126 to 203 in eb4c4a3

	console.log(`--- ${create ? 'CREATE' : 'READ'}`);
	/**
	* UIView
	* -> Shadow
	*
	*
	* UIView
	* -> UIView
	* -> Shadow
	*/
	if (!nativeView) {
	return null;
	}
	if (!nativeView.layer) {
	// should never hit this?
	console.log('- no layer! -');
	return null;
	}
	// if the nativeView's layer is the shadow layer?
	if (nativeView.layer.name === name) {
	console.log('- found shadow layer - reusing.');
	return nativeView.layer;
	}
	console.log('>> layer :', nativeView.layer);
	if (nativeView.layer.sublayers?.count) {
	const count = nativeView.layer.sublayers.count;
	for (let i = 0; i < count; i++) {
	const subLayer = nativeView.layer.sublayers.objectAtIndex(i);
	console.log(`>> subLayer ${i + 1}/${count} :`, subLayer);
	console.log(`>> subLayer ${i + 1}/${count} name :`, subLayer.name);
	if (subLayer.name === name) {
	console.log('- found shadow sublayer - reusing.');
	return subLayer;
	}
	}
	// if (nativeView instanceof UITextView) {
	// return nativeView.layer.sublayers.objectAtIndex(1);
	// } else {
	// return nativeView.layer.sublayers.objectAtIndex(nativeView.layer.sublayers.count - 1);
	// }
	}
	// else {
	// layer = nativeView.layer;
	// }
	// we're not interested in creating a new layer
	if (!create) {
	return null;
	}
	console.log(`- adding a new layer for - ${name}`);
	const viewLayer = nativeView.layer;
	const newLayer = CALayer.layer();
	newLayer.name = name;
	newLayer.zPosition = 0.0;
	// nativeView.layer.insertSublayerBelow(newLayer, nativeView.layer)
	// newLayer.insertSublayerAtIndex(nativeView.layer, 0)
	// nativeView.layer.zPosition = 1.0;
	// nativeView.layer.addSublayer(newLayer);
	// nativeView.layer = CALayer.layer()
	nativeView.layer.insertSublayerAtIndex(newLayer, 0);
	// nativeView.layer.insertSublayerAtIndex(viewLayer, 1)
	// nativeView.layer.replaceSublayerWith(newLayer, nativeView.layer);
	return newLayer;
	}

removing the early return yields the following:

With some logging - here are the resulting layers:

Haven't had a closer look at your plugin, or what it does differently - but if you want you can try the above:

• run the toolbox app -> box-shadow -> toggle solid background -> apply shadow
• comment out the return in the native-helper.ios.ts and let the test logic run
• make any adjustments in there to see if there's a way to move that shadow layer below the actual view...

I guess the difference is that in your plugin you have a fillColor property - and not the regular backgroundColor/backgroundImage I guess, so you have more control of the drawing there?

I see, I get it now! To solve this, we can apply view background color to shadow layer.
After all, it's only the color that's on the bottom.

Seeing where this goes, perhaps we should stop setting background color to native views directly and have a backgroundLayer that replaces shadow and border layers functionality, and background color would also apply to it. It could be used for multiple purposes.