iTween in Handlers such as OnPointerDown, OnBeginDrag,OnDrag Etc

@adriandevera I must qualify by saying I've not used iTween. I'm an old hand in software engineering and related 3D rendering/physics/gaming work, but I am recent to Unity. That said, a few points about dragging should be considered with care.

As you know, Update and FixedUpdate are called periodically as a means of performing work in sync with important engine operations. Update will typically run at 60 calls per second, in line with the display sync (though it can be other speeds, even odd and unequal times when under load).

Mouse operation is not in sync with the engine. It does not run at the frame rate or the physics engine rate. It runs as an interrupt, way under the hood, which then feeds message traffic in real time. Drag is basically a stream of calls at a rate determined by the mouse itself, showing the stream of incoming coordinate positions as the mouse moves. Some mice can run 1200 of these messages per second, others 200, with any rate between depending on model, driver and possibly configuration. The operating system and mouse driver determine that rate, somewhat dictated by the hardware.

My reading is that iTween is expecting 1 call. It will then animate the transition over time at an engine oriented Update cycle until it is completed. A call to iTween like this should (I must assume by comparison to two decades of experience with other tools similar to it) start an animation cycle that operates frame by frame to perform the activity, scaling over 0.3 seconds in this case. OnDrag, as you've posted it, will stuff that with hundreds, possibly thousands of repeated calls to scale the object over 0.3 seconds. It is probably choking.

Like I said, I don't know iTween, but there's a chance it can't operate from OnDrag. If they accounted for calls from mouse messaging, perhaps I'm wrong, but if they don't account for the nature of OnDrag being out of cycle with Update, perhaps the call to iTween should be made in Update after OnDrag sets some bool or other state information to indicate the iTween scale should be requested. In any case, if iTween does not permit you to cancel an operation in progress, you'll have to consider how to stop the scaled effect when the mouse button ends the drag, even if the scale hasn't completed (that is, the mouse stops dragging within the 0.3 second time frame of the scale). Perhaps iTween at least lets you detect when the requested operation is still in progress, and when it is completed. That could be your hook to solve that particular UI timing issue.

In your working version (changing transform's scale) will also be repeating on every OnDrag call, but it will be of no consequence, it is the same on every call. Keep in mind, you're also creating new Vector3's at whatever rate the mouse updates when you create a new scaleCardToBeDragged. Since it is always the same, you shouldn't, even though it appears to be working. What you need is to check the state of drag initialization, do that once, set the transform, then avoid repeating all of that (creating of the Vector3 and re-assigning the transform) during each OnDrag. The transform.position update, on the other hand, is obviously more functional as it tracks the mouse. Even this is going to likely happen much more often and rapidly than Update can fire, which suggests all those new Vector3's should be avoided, and it is possible. You can drop updates to a sustained Vector3 member's x, y and z.

This is merely a foreshadow to what I'm about to suggest regarding the call to iTween, and to the update of the position. iTween should be called only once at drag initialization, not on every OnDrag message.

I'm recommending that the position updates you've exampled here are happening too frequently and creating too many Vector3's without good cause. There are too many possible solutions for me to pick one for you, but at least stop making new Vector3's just because they seem to be a local concept. This repeats too fast for that to be a good idea. Create a Vector3 member to be used by OnDrag, allocate a Vector3 for it, and update the x, y and z values directly in OnDrag.

None of this has dealt with the drag's end, where scale should be returned (and you may, then, want to iTween that). The hint is that you may do well to think in terms of OnDrag (or other mouse events that start and end the drag) as preparing "messages" to be discovered by Update. In other words, it may be better for iTween and all other design issues to not perform updates to the transform.position or the call to iTween within drag event messages, but in Update. Merely let the drag events drop 'commands' by setting bools and other information, like that sustained Vector3 I suggested for position. That way transform.position, which is a property that may call unknown operations when updated, is only changed at the Update cycle, and not at the OnDrag speed.

Likewise, since it appears you have some synchronization issues with iTween (if drag is ended in 0.1 seconds, what do you do?), you could let this disconnection between drag events and Update be a means of handling that. If, for example, iTween is scaling downward over 0.3 seconds, but the drag ends in 0.1 seconds, what would you expect would happen if another iTween call were made to upscale, or a quick change of transform.localScale happened, while that original iTween scaling downward were still in progress? I have no idea myself, but it sounds like a problem. That problem could be solved by letting Update make the calls to iTween based on state information, which can then be independent of the actual timing of the drag events (including drag start, drag end and drag move).

In this way you can allow Update to determine of the drag has been ended before the iTween animation completed, and schedule the return to normal scale appropriately.

I found that this was the best solution i was able to come up with. Note to properly setup Interface Handlers please see the post by diegoleao: https://forum.unity.com/threads/ibegindraghandler-idraghandler-ienddraghandler-script-attached-to-sprite-object.294168/

 using UnityEngine;
 using System.Collections;
 using UnityEngine.EventSystems;
 
 public class TestScale : MonoBehaviour, IPointerDownHandler, IPointerUpHandler
 {
 
     private Vector3 scaleUp = new Vector3(2.0f, 2.0f, 2.0f);
     private Vector3 scaleNormal = new Vector3(1.0f, 1.0f, 1.0f);
 
     public enum AnimationStates
     {
         NORMAL = 0,
         SCALING
     }
 
     [SerializeField]
     private AnimationStates animationState;
 
     public void OnPointerDown(PointerEventData pointerEventData)
     {
         animationState = AnimationStates.SCALING;
     }

     public void OnPointerUp(PointerEventData eventData)
     {
         animationState = AnimationStates.NORMAL;
     }
 
     void Update()
     {
         switch (animationState)
         {
             case AnimationStates.NORMAL:
                 iTween.ScaleUpdate(gameObject, scaleNormal, 0.3f);
                 break;
             case AnimationStates.SCALING:
                 iTween.ScaleUpdate(gameObject, scaleUp, 0.3f);
                 break;
         }
         
     }
 
 }